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PREFACE 


This  development  specification  covers  the  work  performed 
under  Air  Force  Contract  F33615-80-C-5155  (ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory ,  Air 
Force  Systems  Command.  Wright-Patterson  Air  Force  Base,  Ohio. 

It  was  administered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shumaker,  ICAM  Program  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Prime 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Company,  Schenectady,  Mew  York,  under  the  direction  of 
Mr.  Alan  Rubenstein.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  Industrial  Automation  Systems  Department , 
Albany,  New  York. 

Certain  work  aimed  at  improving  Test  Bed  Technology  has 
been  performed  by  other  contracts  with  Project  6201  performing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  communications  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  from  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  documentation  system  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors 

Boeing  Military  Aircraft 
Company  ( BMAC ) 

D.  Appleton  Company 
(DAC0M) 


General  Dynamics/ 
Ft.  Worth 


Role 

Reviewer 


Responsible  for  IDEF  support, 
state-of-the-art  literature 
search 

Responsible  for  factory  view 
function  and  information 
models 
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Subcontractors 

Illinois  Institute  of 
Technology 

North  American  Rockwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 

TASKS  4.5  -  4.9  (TEST  BED) 

Subcontractors 

Boeing  Military  Aircraft 
Company  (BMAC) 

Computer  Technology 
Associates  (CTA) 

Control  Data  Corporation 
(CDC) 


D.  Appleton  Company 
(DACOM) 


Role 

Responsible  for  factory  view 
function  research  (IITRI) 
and  information  models  of 
small  and  medium- size  business 

Reviewer 

Responsible  for  factory  view 
function  and  information 
models 

Responsible  for  IDEP2  support 
Responsible  for  IDEFO  support 


Role 

Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  computer  technology. 

Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 

Responsible  for  the  Common  Data 
Model  (CDM)  implementation  and 
part  of  the  CDM  design  (shared 
with  DACOM). 

Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 
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Role 


Subcontractors 

Digital  Equipment 
Corporation  (DEC) 


McDonne 1 1  Doug 1 as 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  8  Dodge) 


Sof Tech ,  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
(SDRC) 


Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 

Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Prime  contractors  under  other  projects  who  have  contributed 
to  Test  Bed  Technology,  their  contributing  activities  and 
responsible  projects  are  as  follows: 

Contractors  ICAM  Project  Contributing  Activities 

Enhancements  for  IBM 
node  use.  Technology 
Transfer  to  Integrated 
Sheet  Metal  Center 
( I SMC) 


Boeing  Military 
Aircraft  Company 
( BMAC ) 


1701,  2201, 
2202 
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Contractors 

ICAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502.  1701 

IISS  enhancements  to 
Common  Data  Model 
Processor  (CDMP) 

D.  Appleton  Company 
(DACOM) 

1502 

IISS  enhancements  to 
Integration  Methodology 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communications 
equipment . 

Hughes  Aircraft 

Company  (HAC) 

1701 

Test  Bed  enhancements 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502.  1701. 
1703 

IISS  enhancements  to 
User  Interface/Virtual 
Terminal  Interface 
(UI/VTI ) 

Systran 

1502 

Test  Bed  enhancements. 
Operation  of  Test  Bed. 
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SECTION  1 
SCOPE 


1 . 1  Identification 

This  specification  establishes  the  development,  test  and 
qualification  requirements  of  a  computer  program  identified  as 
the  Neutral  Data  Definition  Language  Processor,  known  in  this 
document  as  the  NDDL  Processor.  The  NDDL  Processor  is  one 
configuration  item  of  the  Integrated  Information  Support  System 
( IISS)  Common  Data  Model  (CDM)  Subsystem. 

1 .2  Functional  Summary 

The  NDDL  processor  is  a  language  used  to  manipulate  and 
populate  information  in  the  Common  Data  Model  (CDM)  of  the  IISS 
System  database.  It  provides  the  user  with  three  modes  of 
operation:  (1)  Batch  Mode  allows  NDDL  command  files  to  be 
executed;  (2)  Interactive  Mode  allows  the  user  to  enter  NDDL 
commands  at  a  terminal;  and  (3)  Forms  Mode  allows  the  user  use 
of  the  IISS  forms  processor  to  display  input  and  output  screens 
of  NDDL  commands.  The  NDDL  processor  allows  the  user  to 
populate  and  maintain  the  three  schemas  of  the  CDM:  an  external, 
conceptual  and  internal  and  the  mappings  between  each.  The  NDDL 
also  provides  capabilities  for  manipulation  of  many  IDEF-1 
models  and  submodels  needed  during  the  process  of  developing  the 
single  integrated  model  of  the  conceptual  schema.  Only  the 
integrated  model  may  be  mapped  to  the  external  and  internal 
schemas.  The  NDDL  was  designed  by  a  joint  working  group  of  IISS 
coalition  members,  described  in  the  Integration  Task  Report, 
Reference  8.  The  language  is  modelled  after  SQL  and  the  command 
features  a  combination  of  a  few  simple  verbs  (operators)  along 
with  the  necessary  parts  of  the  CDM  (objects).  The 
functionality  of  NDDL  is  summarized  in  the  matrix  of  Figure  1-1 
The  following  notes  refer  to  the  foot  notes  of  the  matrix. 
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1.  Internal  Schema  Objects  are  defined  rather  than  created 
since  IISS  assumes  internal  schema  describes  actual, 
previously  existing  databases. 

2.  DESCRIBE  serves  the  purpose  of  creating,  altering  and 
dropping  descriptions  for  the  applicable  objects. 

3.  Aliases  are  maintained  for  entities  and  attributes 
only . 

4.  Keywords  are  maintained  only  for  entities,  attributes 
and  relations.  They  can  only  be  created  when 
associated  with  entities,  attributes  or  relations. 

5.  The  noted  objects  can  only  be  altered  through  use  of 
DROP  and  CREATE  operators. 

6.  ALTER  commands  generally  have  ADD,  DROP  and  ALTER 
suboperators  for  subobjects . 

7.  Data  items  are  created  and  dropped  as  subobjects  of 
views . 

8.  Data  types  are  created  and  dropped  as  subobjects  of 
domains . 

9.  Data  fields  are  created  as  subobjects  of  records. 

10.  Maps  do  not  have  names  of  their  own  and  cannot  be 
renamed  or  described. 


msmmm 
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Figure  1-1.  NDDL  Functionality  Matrix 
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SECTION  2 
DOCUMENTS 


2.1  Reference  Documents 


1.  General  Electric  Co.,  Test  Bed  System  Requirement 
Document  (Draft);  SRD620140000,  Revised  23  August  1982. 

2.  General  Electric  Co.,  Test  Bed  System  Design 
Specification;  SDS620140000 ,  7  February  1983. 

3.  ICAM  Documentat i on  Standards ;  IDS15012000A ,  28 

December  1981 . 

4.  General  Electric  Co.,  IISS  Software  Development 
Guidelines/Conventions  (Draft);  23  August  1982. 

5.  Structural  Dynamics  Research  Corporation,  IISS  User 
Interface  Management  System  Services  User  Manual ; 
UM626144100A,  July,  1983. 

6.  Structural  Dynamics  Research  Corporation,  IISS  Form 
Processor  Users  Manual ;  UM620144200A ,  5  December  1984. 

7.  Control  Data  Corporation,  IISS  Neutral  Data  Definition 
Language  ( NDDL )  User ' s  Guide  (Preliminary  Draft);  28 
February  1985 . 

8.  Hughes  IISS  Integration  Task;  16  April  1984. 

9.  Softech,  ICAM  Architecture,  Part  II,  Vol .  V, 

Information  Modelling  (IDEF1) ;  FTR1 10210000 . 

10.  D.  Appleton  Co.,  CDM  Administrator * s  Manual ; 

UM620 141 000 ,  March  1984. 

11.  D.  Appleton  Co.,  CDM1-IDEF,  Model  of  the  Common  Data 
Mode 1 ;  CCS620141000 ,  15  May  1985. 

12.  General  Electric  Co.,  Quality  Assurance  Plan ; 
QAP620144000 ,  4  January  1984. 


2-1 


DS  620141100 
1  November  1985 


13.  D.  Appleton  Co.,  Embedded  NDML  Programmer  *  s  Reference 
Manual ;  PRM620141200 .  March,  1985. 

14.  Softech,  Inc.,  NTM  Programmer  *  s  Guide;  UM620140001 , 
July,  1984. 

2.2  Terms  and  Abbreviations 


Attribute  Use  Class :  ( AUC ) . 

Application  Interface:  (AI)  A  collection  of  routines  with  the 
same  calling  sequences  as  the  Forms  Processor  and  Virtual 
Terminal  callable  routines  that  enables  applications  to  be 
hosted  on  computers  other  than  the  host  of  the  User  interface. 

Assertion:  Predicate  that  applies  to  one  or  more  attributes; 

checked  after  completion  of  an  action  to  determine  if  the 
results  should  be  committed. 

Conceptual  Schema :  ( CS ) . 

Common  Data  Model  Processor:  (CDMP). 

Common  Data  Model:  (CDM)  Describes  common  data  application 
process  formats,  form  definitions,  etc,  of  the  IISS  and  includes 
conceptual  schema,  external,  internal  schemas,  and  schema 
transformation  operators. 

Data  Field:  (DF)  An  element  of  data  in  the  internal  schema. 
Generally,  it  is  by  this  name  a  DBMS  will  reference  data. 

Data  Item:  (DI)  An  element  of  data  in  the  external  schema.  It 
is  by  this  name  that  an  NDML  programmer  references  data. 

Data  Type :  A  specific  computer  representation  of  a  domain. 

Distributed  Request  Supervisor:  (DRS)  This  IISS  CDM  Subsystem 
configuration  Item  controls  the  execution  of  distributed  NDML 
queries  and  non  distributed  updates. 

Domain:  A  logical  definition  of  legal  attribute  class  values. 

Domain  Constraint:  Predicate  that  applies  to  a  single  domain. 


External  Schema:  (ES). 
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Forms :  Structured  views  which  may  be  imposed  on  windows  or 
other  forms.  A  form  is  composed  of  fields  where  each  field  is  a 
form,  item,  or  window. 

Forms  Processor:  (FP)  A  set  of  callable  execution  time  routines 
available  to  an  application  program  for  form  processing. 

Internal  Schema :  (IS). 

Integrated  Information  Support  System:  (IISS)  A  test  computing 
environment  used  to  investigate,  demonstrate  and  test  the 
concepts  of  information  management  and  information  integration 
in  the  context  of  Aerospace  Manufacturing.  The  IISS  addresses 
the  problems  of  integration  of  data  resident  on  heterogeneous 
databases  supported  by  heterogeneous  computers  interconnected 
via  a  local  Area  Network. 

Mapping:  The  correspondence  of  independent  objects  in  two 
schemas:  ES  to  CS  or  CS  to  IS. 

NDDL  User :  The  CDM  administrator  or  his  designated 
representat i ve . 

Network  Transaction  Manager:  (NTM)  Performs  the  coordination, 
communication  and  housekeeping  functions  required  to  integrate 
the  Application  Processes  and  System  Services  resident  on  the 
various  hosts  into  a  cohesive  system. 

Neutral  Data  Definition  Languages :  (NDDL)  A  language  used  to 
manipulate  and  populate  information  in  the  Common  Data  Model 
(CDM)  or  IISS  System  Database. 

Neutral  Data  Manipulation  Language:  (NDML)  A  language  developed 
by  the  IISS  project  to  provide  uniform  access  to  common  data, 
regardless  of  database  manager  or  distribution  criteria.  It 
provides  distributed  retrieved  and  single  node  update. 

ORACLE :  Relational  DBMS  based  on  the  SQL  (Structured  Query 
Language,  a  product  of  ORACLE  Corp,  Menlo  Park,  CA).  The  CDM  is 
an  ORACLE  database . 

Object:  Named  Common  Data  Model  item;  for  example;  entity 

class,  relation  class,  attribute  class. 

Trigger :  Action  that  is  invoked  at  the  commit  completion  of 

another  action. 
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User  Interface :  (UI)  Controls  the  user's  terminal  and 
interfaces  with  the  rest  of  the  system. 

Virtual  Terminal  Interface:  (VTI)  Performs  the  interfacing 
between  different  terminals  and  the  UI.  This  is  done  by 
defining  a  specific  set  of  terminal  features  and  protocols  which 
must  be  supported  by  UI  software  which  constitutes  the  virtual 
terminal  definition.  Specific  terminals  are  then  mapped  against 
the  virtual  terminal  software  by  specific  software  modules 
written  for  each  type  of  real  terminal  supported. 


i * 
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SECTION  3 
REQUIREMENTS 


3. 1  Computer  Program  Definition 

The  NDDL  processor  is  the  computer  program  that  translates 
the  command  statements  of  this  language  and  performs  the 
operations  requested,  updating  the  CDM  database.  The  NDDL 
language  is  non-procedural.  The  NDDL  processor  is  essentially 
an  interpreter,  executing  one  command  at  a  time,  in  the  order 
presented  by  the  user . 

Each  command  is  parsed  for  syntactic  correctness.  Control 
is  transferred  to  the  individual  command  processor  for  the 
semantic  validation  of  the  command.  If  all  semantic  checks  are 
found  to  be  correct,  the  database  is  updated  or  information 
retrieved . 

3.1.1  System  Capacities 

The  NDDL  is  designed  to  allow  multiple  users  at  the  sane 
time.  Data  limits  are  imposed  only  by  the  capacity  of  the  DBMS. 
Processing  speed  limits  are  imposed  by  the  speed  of  the  computer 
and  the  number  of  other  users  and  the  speed  and  efficiency  of 
the  NTM  subsystem  and  the  IISS  Forms  Processor.  A  number  of 
COBOL  and  C  fixed  size  tables  will  be  used  to  temporarily  hold 
information.  These  limits  can  be  changed  very  easily  in  a 
virtual  memory  environment. 

3.1.2  Interface  Requirements 

The  NDDL  processor  shall  make  use  of  the  IISS  Forms 
Processor  for  command  input  and  shall  allow  batch  input  as  well. 
The  NDDL  processor  shall  make  use  of  IISS  NDML  wherever  possible 
to  retrieve  data  from  the  CDM  native  ORACLE  wherever  NDML  is  not 
sufficient . 
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3. 1.2.1  Interface  Block  Diagram 
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Figure  3-1.  NDDL  Processor  Interfaces 
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3. 1.2. 2  Interface  Requirements 

The  NDDL  processor  makes  use  of  the  IISS  Forms  Processor 
directly  for  forms  interactive  input.  NDDL  also  makes  use  of 
the  standard  C  input/output  library  to  allow  user  non-forms 
interactive  input  or  batch  input  via  file  redirection.  Database 
access  is  through  a  combination  of  (1)  ORACLE  for  update  insert 
and  delete  and  recursive  searches  not  supported  by  NDML  and  (2) 
NDML  for  all  other  searches.  The  NDML  routines  are  precompiled 
by  the  IISS  NDML  precompiler  and  ORACLE  request  processors  are 
generated,  which  communicates  with  NDDL  through  the  DRS  which 
uses  IISS  NTM  services. 

It  is  a  design  goal  to  replace  the  use  of  ORACLE  with  NDML 
to  achieve  DBMS  independence,  and  to  allow  the  CDM  database 
itself  be  distributed. 

It  is  a  design  goal  to  make  NDDL  an  application  controlled 
by  the  IISS  User  Interface  subsystem  to  make  use  of  its 
capabilities.  Currently  there  is  an  interface  problem  with  the 
C  library  of  I/O  routines  supplied  with  the  IS/1  workbench  and 
the  UIMS. 

3.2  Detailed  Functional  Requirements 

This  description  of  functional  requirements  is  broken  down 
into  nine  subfunctional  areas.  These  areas  are  identified  in 
the  block  diagrams.  Figure  3-2  which  includes  the  following 
paragraph  numbers.  The  forty-two  commands  currently  making  up 
NDDL  are  each  described  in  Section  3.2.8. 


DS  620141100 
1  November  1985 


+ - 

I 

V 

+ - + 

I  INITIALIZATION! 

I  I 

I  3.2.1  I 

+ - + 


+ 


V 

+ - + 

I  INPOT/OUTPUT  I 
I  3.2.2  I 


+ - + 

I  NDDL  I 

- I  PROCESSOR  I - + 

+ - 1  3.2  I - +  I 

V  + - +  V  V 


*  ,  t  r  i - t 

I  PARSE  I  I GENERAL  COMMAND!  (TERMINATION! 

I COMMANDS  I  I  PROCESSING  I  I  I 

I  3.2.4  I  I  3.2.  I  I  3.2.7  I 

+-+ - +  + - + - +  + - + 

I  I 

— +  + - + - + 

++ - + - +  | 

++ - V - +1  I 

+ - 1  INDIVIDUAL  COMMAND  ++_+__  + 

I  I  PROCESSING  I+-+  I 

I  >  3.2.8  ++  I 

V  + - +  V 

+ - +  + - 4 


-I  ERROR  HANDLING  I  I  DATABASE  ACCESS  I 

I  3.2.3  I  I  3.2.5  I 


3-4 


DS  620141100 
1  November  1985 


3.2.1  Initialization 


A .  Function : 

Initialization  will  allow  the  NDDL  processor  to  perform 
all  initialization  requirements  with  other  subsystems 
and  software  environments. 

B.  COM  Requirements: 

None 

C .  Processing : 

1.  Determine  the  processing  mode:  either  interactive, 
through  forms ,  or  batched . 

2.  Initialize  with  NTM  through  use  of  INITEX  service. 

In  the  future,  this  should  be  changed  to  INITAL  when 
UI  services  are  required. 

3.  If  in  forms  mode,  initialize  to  the  forms  processor 
by  using  the  INITFP  service,  OPNFRM  and  ADDFRM  to 
create  the  user's  initial  form. 

4.  Logon  the  ORACLE  DBMS  and  open  all  cursors 
necessary.  The  logon  data  area  and  cursors  will  all 
be  global  data  structures. 

5.  Initialize  any  other  data  structures  necessary  for 
any  commands  to  their  null,  or  initial  state. 

6.  Initialize  any  other  global  variables  such  as 
current  model,  current  database,  etc. 

3.2.2  Input/Output 

A .  Function : 

Provide  user  input  to  the  other  components  of  the  NDDL 
processor  in  an  invisible  manner,  without  respect  to 
the  means  in  which  the  input  was  obtained.  Provide 
output  for  NDDL  processor  to  the  user  through  a 
standard  interface  to  allow  the  same  invisibility. 

B .  CDM  Requirements: 
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None 

C.  Processing: 

The  standard  C  character  input/output  routines  will  be 
used.  They  will  be  modified,  however,  to  recognise  the 
current  input/output  mode.  Batch  mode  will  use  the 
existing  capability  of  the  C  library.  Interactive  node 
will  make  use  of  forms  processor  calls.  Because  the 
forms  processor  can  return  many  screens  of  information 
at  a  time,  the  modified  input/output  routines  shall 
extract  a  single  character  at  a  time  from  the  data 
structures.  Since  output  consists  of  simple 
information  messages  to  the  user.  PMSGLS  forms 
processor  calls  can  be  used  for  all  messages  or  PRINTF , 
if  batch  mode,  to  standard  output.  Output  of  generated 
NDDL  uses  the  standard  C  file  I/O  primitives. 

3.2.3  Error  Handling 

A.  Function: 

Provide  a  single  standard  means  of  communicating  errors 
to  the  NDDL  user.  The  interface  shall  be  simple, 
readily  usable  and  invisible  to  the  particular 
input/output  mode.  The  error  handling  shall  also  make 
database  transaction  rollback  conditions  simple  to 
recognize.  User  requirements  for  command  skipping 
after  a  semantic  error  shall  be  implemented. 

B.  CDM  Requirements: 

None 

C.  Processing : 

Three  major  entry  points  to  the  error  handling 
functionality  of  NDDL  shall  be  established 
corresponding  to  the  three  types  of  errors.  These  are: 

1.  An  entry  point  for  “fatal"  errors.  These  are 

errors  from  other  subsystems  or  software  than  NDDL. 
These  errors  are  to  be  handled  in  accordance  with 
the  I ISS  Error  Handling  Philosophy,  Reference 
Number  12.  A  standard  routine  is  called  to  log  the 
message  in  a  central  place.  These  error  conditions 
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shall  also  be  communicated  to  the  user  as  type  2 
below . 

2.  An  entry  point  for  user  errors.  These  are  errors 
that  are  caused  by  the  user  and  can  be  recovered  by 
user  action.  An  example  may  be  creating  an  entity 
that  already  exists.  This  error  handler  must  set  a 
flag  so  at  the  end  of  the  command,  any  database 
changes  are  backed  out  through  a  rollback  procedure 
supplied  by  the  DBMS  or  NDML. 

3.  An  entry  point  for  warning  messages.  These  are 
indications  of  problems  of  user  understanding,  such 
as  dropping  a  set  that  does  not  exist,  or  simple 
informative  messages  about  actions  that  have 
occurred,  such  as  ‘model  altered". 

It  is  the  responsibility  of  the  general  command 
processor.  Section  3.2.6,  not  to  process  commands 
in  batch  after  a  user  error  or  fatal  error  has 
occurred.  This  prevents  a  later  command  from 
causing  unpredictable  harm. 

3.2.4  Parse  Commands 


A .  Function: 

The  Parse  Command  subfunction  of  IISS  will  provide  a 
mechanism  for  accepting  user  command  input,  validating 
correct  syntax,  reporting  syntax  errors  and  saving 
pertinent  command  information  in  data  structures 
independent  of  the  syntax. 

B .  CDM  Requirements: 

None 

C .  Processing : 

This  function  will  be  provided  through  code  generated 
by  the  UNIX  tools  YACC  and  LEX  and  interface  routines 
provided  as  part  of  this  function  (UNIX  is  a  trademark 
of  Bell  Labs). 

1.  LEX  is  a  tool  that  generates  lexical  analyzers. 
Given  a  specification  of  the  reserved  words  or 
tokens,  LEX  will  generate  a  routine  that  will 
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accept  user  input  and  return  control  to  the  caller 
on  each  token  recognized. 

2.  YACC  is  a  tool  that  generates  a  parser  that 
validates  user  input  as  matching  the  grammar  or 
syntax  of  the  language.  The  parser  generated  has 
the  capability  of  calling  user  specified  routines 
or  code  called  'actions'*.  YACC  is  commonly  used  in 
compiler  construction.  YACC  uses  a  syntax 
specification  of  the  NDDL  commands  and  generates 
the  NDDL  parser.  This  specification  is  not  treated 
as  an  IISS  deliverable  because  to  do  so  would 
require  the  user  or  target  site  to  have  the  UNIX 
tools . 

3.  Token  primitive  routines  will  be  developed  that 
store  user  entered  command  data,  or  tokens,  in  a 
special  data  structure.  This  data  structure  is 
simply  a  matrix  of  pointers  into  a  string  of 
concatenated  tokens.  The  columns  of  the  matrix  are 
called  lists.  Lists  generally  have  like  tokens; 
for  example,  all  the  keywords  entered  on  a  CREATE 
ENTITY  command.  The  rows  of  the  matrix  are 
generally  meaningless,  unless  the  syntax  defines  a 
special  correspondence  between  lists.  An  example  is 
CREATE  VIEW,  where  data  items  and  attributes  must 
match  up. 

The  token  primitives  are  the  only  kind  of  action 
statements  used  in  the  YACC  input.  It  is 
conceivable  that  each  entire  command  processor 
could  be  called  as  YACC  action  statements,  but  this 
is  not  the  case.  The  design  goal  was  to  build 
command  processors  independent  of  the  input 
mechanism,  in  this  case,  command  syntax. 

3.2.5  Database  Access 
A.  Function: 


This  subfunction  outlines  the  functional  requirements 
of  the  database  access  used  in  the  NDDL  processor.  All 
database  access  shall  be  for  the  ORACLE  based  CDM.  All 
database  access  shall  use  the  facilities  of  the  IISS 
NDML  wherever  possible.  The  ORACLE  SQL  facilities  may 
be  substituted  only  if  the  NDML  does  not  provide  the 
needed  functionality.  Any  use  of  ORACLE'S  SQL  shall  be 
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written  in  C.  This  is  because  the  necessary  logon 
database  area  and  cursors  must  be  kept  in  a  global  area 
to  avoid  the  database  access  routines  requiring  any 
DBMS  specific  interface  parameters.  This  is  to  allow 
eventual  conversion  of  all  ORACLE  database  access 
routines  to  NDML  and  achieve  DBMS  independence  for  the 
MDDL  processor. 

B.  COM  Requirements: 

The  ORACLE  DBMS  must  be  used  due  to  previous  decisions 
on  the  initial  DBMS  to  host  the  CDM. 

C .  Processing : 

1.  ORACLE  SQL  will  be  used  for  the  following 
requirements : 

1.1  SELECT  where  sorting  is  required. 

1.2  SELECT  where  a  Bill  of  Materials  type 
recursive  search  is  needed. 

1.3  INSERT  operations.  Insert  modules  will  insert 
a  single  row  at  a  time. 


tar.' 


1 . 4  DELETE  operat i ons . 

1.5  UPDATE  (or  MODIFY)  operations. 


2. 


COBOL  embedded  NDML  will  be  used  for  all  other 
database  retrieval  and  verification  modules.  A 
distinction  is  made  between  verification  or  look  up 
modules  and  modules  expected  to  retrieve  more  than 
one  row. 


2.1 


The  verification  type  module  shall  be  called 
with  the  search  parameters  as  inputs  and  the 
database  value(s)  found  on  the  single  row  as 
output.  Very  often  a  zero  valued  object 
number  will  be  used  as  a  "no-find"  status. 


2.2 


For  routines  expected  to  find  many  rows,  the 
routine  will  receive  the  simple  search 
parameters  as  input  as  before.  Within  the 
NDML  {  and  },  logic  will  be  coded  for 
processing  each  row.  Very  often  calls  to 
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other  routines  which  nay  process  a  single  row 
will  be  Bade.  If  row  processing  is  simple 
enough,  calls  are  not  necessary. 

These  requirements  promote  DBMS  independence  and 
simplicity  of  data  structures  common  to  more  than 
one  module. 

3.  For  purposes  of  database  concurrency  and  integrity, 
the  logical  unit  of  work  shall  be  defined  to  be  a 
single  NDDL  command  execution.  That  is,  the 
command  is  wholly  executed  with  the  results  as 
expected  by  the  user  or  none  of  the  command  is 
executed.  Therefore,  an  HDDL  command  can  be 
considered  a  transaction. 

3.2.6  General  Command  Processing 

A .  Funct i on 

General  Command  Processing  will  handle  such  functions 
as  pre-command  initialization,  control  of  parsing, 
control  of  forms  input/output,  and  post  command  control 
of  database  commit  or  rollback.  It  must  also  control 
parsing  of  commands  that  cannot  be  executed  due  to 
previous  errors.  This  subfunction  will  also  provide 
facilities  for  CDM  object  numbering  and  number  reuse. 
The  subfunction  must  provide  for  generalized  access  to 
the  parser  data  structures . 

B.  CDM  Requirements 

Two  tables  necessary  for  object  numbering  will  be  used. 
These  are:  (1)  NEXTNUMBER  which  contains  the  next 
number  to  be  used  for  each  object  type;  and  (2) 
REUSABLENUMBER  which  contains  all  the  object  numbers 
dropped  and  available  for  reuse. 

C .  Processing 

1.  The  user  input  form  must  be  displayed  the  first 
time  in  forms  mode. 

2.  Each  command  entered  by  the  user  on  the  input 
screen  must  be  processed;  skipping  commands  after 
an  error  is  encountered. 
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3.  For  a  completed  command,  a  count  of  errors  must  be 
displayed . 

4.  If  these  were  errors,  the  entire  screen  must  be 
redisplayed.  Also,  the  previous  set  of  error 
messages  need  to  be  blanked  out  and  a  "no  errors" 
message  displayed.  If  the  user  asked  to  refresh 
and  keep  his  command  on  the  screen,  this  too  must 
be  done. 

5.  The  current  database  and  model  must  also  be  kept  on 
the  screen. 

6.  If  the  user  entered  the  quit  key,  a  halt  command 
must  be  generated  and  processed. 

7.  When  a  user  has  entered  a  command,  the  parser  must 
be  called.  The  return  status  of  parsing  must  be 
examined. 

8.  If  the  command  is  to  be  processed,  then  a  routine 
to  effect  the  transfer  of  control  to  the  proper 
command  processor  is  executed. 

9.  After  the  individual  command  is  executed,  the 
current  model  and  database  must  be  established.  If 
the  command  was  successful ,  the  database 
transactions  are  committed  or,  if  unsuccessful, 
rolled  back. 

10.  The  CDM  objects  that  shall  be  numbered  follow. 

Each  object  type  below  has  an  object  type  number. 


OBJECT  TYPE  NUMBER 


OBJECT  TYPE 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 


MODEL 

ENTITY 

ATTRIBUTE 

KEY  CLASS 

RELATION 

TAG 

DOMAIN 

KEYWORD 

VIEW 

DATABASE 

SET 

DATA  TYPE 
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13 

DATA  ITEM 

14 

DATA  FIELD 

15 

RECORD 

Objects  are  numbered  to  ease  in  renaming  and  to 
allow  a  central  place  for  storing  object 
descriptions . 

Two  subfunctions  shall  exist  to  promote  consistent 
handling  of  these  numbers. 

10.1  Adding  a  reusable  number  shall  make  the 
number  of  a  dropped  object  available  for 
reuse  by  storing  it  in  the  CDM's 
REUSABLENUMBER  table. 

10.2  Get  next  number  will  obtain  a  new,  unused 
number  for  an  object  being  created.  It  must 
first  search  the  list  of  available  numbers 
for  this  object  type.  If  one  is  found,  it  of 
course  must  be  deleted  from  the  list  of 
reusable  numbers.  If  one  is  not  found,  the 
next  available  number  is  retrieved  from  the 
CDM's  NEXT_NUMBER  table.  This  number  is 
incremented  and  updated  in  the  NEXTNUMBER 
table . 

11.  Finally,  this  subfunction  must  supply  routines  that 
allow  the  command  processor  to  access  the  lists  of 
user  command  tokens  built  by  the  parser.  These 
functions  shall  allow  access  to  the  first  token  on 
the  list,  the  next  token  from  the  list  and 
accessing  a  token  from  one  list  corresponding  to 
another  list  (same  row).  The  functions  should 
return  a  count  of  tokens  on  the  list  and  an  end  of 
list  indicator. 

3.2.7  Termination 


A .  Function 

Termination  will  allow  the  NDDL  processor  to  perform 
all  termination  requirements  with  other  subsystems  and 
software  environments. 
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B.  CDM  Requirements 
None 

C.  Processing: 

1.  Close  all  ORACLE  cursors  and  log  off  from  ORACLE. 

2.  If  the  forms  mode  of  input  was  used,  use  the  FP 
service  TERMFP. 

3.  Issue  a  call  to  send  a  finish  up  message  to  the  DRS 
and  to  terminate  NTM  activities. 

3.2.8  Individual  Command  Processing 

The  following  subparagraphs  outline  the  functional 
requirements  of  each  command  making  up  the  NDDL.  Consult  the 
Table  of  Contents  for  a  quick  reference  to  a  specific  command. 

3.2.8. 1  ALTER  ALIAS  -  Switch  the  primary  and  alias  names  of  a 
conceptual  attribute  or  entity. 

A.  Funct i on : 

Alter  Alias  performs  the  following  functions: 

1.  changes  the  primary  name  of  an  attribute  or 
entity  to  alias; 

2.  changes  the  alias  name  of  an  attribute  or 
entity  to  primary. 

B.  CDM  Requirements: 

1.  The  primary  name  of  the  attribute  or  entity 
must  exist  in  the  current  model. 

2.  The  alias  name  of  the  attribute  or  entity  must 
exist  in  the  current  model. 

C .  Processing : 

1.  Alter  Alias  verifies  that  the  primary  and  alias 
names  to  be  switched  exist  in  the  current 
model . 
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If  attribute  names  are  being  switched,  the 
primary  and  alias  entries  in  the  ATTRIBOTENAME 
table  are  updated. 

If  entity  names  are  being  switched,  the  primary 
and  alias  entries  in  the  EHTITYNAME  table  are 
updated. 
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COM  TABLES  ACCESSED  -  ALTER  ALIAS  (S-SQL  N 

TABLE  NAME _ SELECT  MODIFY  IMSERT 

ENTITYCLASS  N(VERNME) 

ENTITYNAME  N(VERNME)  S(OPDECAL) 

ATTRIBUTECLASS  N ( VERNMA ) 

ATTRIBUTE  NAME  N(VERNMA)  S(UPDACAL) 


NDML) 

DELETE 
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3. 2. 8. 2  ALTER  ATTRIBUTE  -  Alter  a  Conceptual  Attribute 
A.  Function: 


Alter  Attlbute  performs  the  following  functions: 

1.  change  a  domain  name  for  an  attribute: 

2.  add  keywords  to  an  attribute: 

3.  drop  keywords  from  an  attribute. 


B.  CDM  Requirements: 

1.  The  attribute  to  be  altered  must  exist  in  the 
current  model . 

2.  If  the  domain  is  to  be  modified,  the  new  domain 
must  exist. 

3.  If  a  keyword  is  to  be  dropped,  it  must  exist. 

C.  Processing: 

1.  Alter  Attribute  verifies  that  the  attribute  to  be 
altered  exists. 

2.  If  the  domain  is  to  be  changed,  the  existence  of 
the  new  domain  is  verified  and  the  ATTRIBUTECLASS 
table  is  modified  to  contain  the  new  domain  number. 

3.  If  a  keyword  is  to  be  dropped,  a  check  is  performed 
to  verify  that  the  keyword  is  assigned  to  the 
attribute.  If  so,  the  keyword  is  deleted  from  the 
AC_KEYWORD  table . 

4.  If  a  keyword  is  to  be  added  to  an  attribute,  the 
keyword  table  is  searched  to  determine  whether  the 
keyword  exists.  If  not,  the  new  keyword  is 
inserted  into  the  keyword  table.  The  new  keyword 
is  then  inserted  into  the  AC_KEYWORD  table,  if  it 
did  not  already  exists  there. 
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CDM  TABLES  ACCESSED  -  ALTER  ATTRIBUTE  ( S-SQL .N-NDML) 


TABLE  MANE 

SELECT 

MODIFY 

INSERT 

DELETE 

AC  KEYWORD 

N  ( ADDWA) 

S  INSKWAC) 

S 

(DELKWAC) 

ATTRIBUTE  CLASS 

M  (VERATT) 

S  ( UPDAC ) 

ATTRIBUTE  MANE 

H  (VERATT) 

DOMAIN  CLASS 

N  (VERDOM) 

KEYWORD 

N  (VERKW) 

S  (INSKW) 
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!  3. 2. 8. 3 


! 

I 
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A. 


ALTER  DOMAIN  -  Alter  the  definition  of  a  domain  in  the 
CDM. 


Funct i on : 


Alter  Domain  allows  the  NDDL  user  to  perform  the 
following  modifications  to  the  definitions  of  existing 
domains : 

1.  addition  of  non-standard  data  types; 

2.  deletion  of  non-standard  data  types; 

3.  changing  the  meta  data  description  of  existing  data 
types  of  the  domain  (i.e.  changing  the  type,  size 
and  number  of  decimal  digits); 

4.  promoting  a  non-standard  data  type  to  standard, 
converting  the  former  standard  to  non-standard. 

B.  CDM  Requirements: 

The  domain  name  referenced  must  be  found  in  the  CDM. 

Any  data  types  to  be  dropped  or  altered  must  already  be 
defined  for  the  domain.  Any  data  types  to  be  added 
must  not  already  be  defined  anywhere  else  in  the  CDM. 
There  must  always  be  a  standard  data  type  for  the 
domain,  i.e.  the  current  standard  data  type  cannot  be 
dropped. 

C.  Processing : 

1.  The  user  entered  domain  naune  to  be  altered  is 
verified  to  be  in  the  CDM.  With  this  number,  each 
of  the  data  type  changes  can  be  processed. 

2.  For  each  user  data  type  request,  determine  if  its 
an  ADD,  DROP  or  ALTER. 

2.1  For  an  ADD  or  ALTER,  the  legal  data  types  are 
checked.  They  must  be  SIGNED,  UNSIGNED, 
INTEGER,  FLOAT,  PACKED,  or  CHARACTER.  The  user 
does  not  enter  this  for  a  DROP. 

2.2  For  an  ADD  and  optionally  for  an  ALTER,  the 
size  and  number  of  decimal  digits  are  checked. 
They  must  both  be  numeric  and  the  decimal 
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digits  Bust  not  exceed  the  size.  They  are  not 
specified  for  a  DROP. 

2.3  If  the  user  has  requested  to  alter  a  data 
type : 

2.3.1  The  data  type  is  verified  to  exist  for  the 
domain  and  be  either  standard  or 
non-standard.  The  user  is  warned  if  it 
cannot  be  found.  If  it  is  a  standard,  only 
type,  size  and  number  of  decimals  may  be 
changed . 

2.3.2  For  standard  data  type,  or  a  change  to  only 
the  type,  size  and  number  of  decimals,  this 
change  is  recorded  in  the  USERDEFDATATYPE 
table. 

2.3.3  Otherwise,  the  user  has  requested  a  switch 
from  non-standard  to  standard.  In  this 
case,  the  old  standard  data  type  name  is 
fetched  and  is  changed  to  non-standard  and 
the  name  specified  by  the  user  is  changed  to 
become  the  standard  data  type. 

2.4  If  the  user  has  requested  to  drop  a  data  type: 

2.4.1  The  data  type  name  is  verified  to  be  in  the 
domain . 

2.4.2  If  the  data  type  is  found  to  be  standard, 
the  user  is  informed  that  it  cannot  be 
dropped . 

2.4.3  If  the  data  type  is  non-standard,  then  any 
usage  of  this  data  type  is  checked. 

2.4.3. 1  The  database  is  searched  to  find  any 
references  by  a  data  field. 

2. 4. 3. 2  The  database  is  searched  to  find  any 
references  by  a  data  item. 

2. 4. 3. 3  The  database  is  searched  to  find  any 
references  by  an  attribute  class.  This  is 
probably  unnecessary  since  it  has  been 
checked  to  be  non-standard  in  2.4.2  and 
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only  standards  can  map  to  attributes. 

2.4.4  If  it  was  not  referenced  elsewhere,  data 
type  and  its  description  text  is  deleted. 

2.5  If  the  user  has  requested  to  add  a  data  type: 

2.5.1  For  a  standard  data  type,  the  database  is 
searched  for  an  existing  standard  data  type. 
If  one  is  not  found: 

2. 5. 1.1  The  data  type  name  is  checked  to  see  that 
it  was  not  used  for  some  other  domain.  If 
not , 

2. 5. 1.2  The  data  type  is  checked  to  be  valid  by 
using  a  database  look  up  in  the  table 
DATATYPE.  If  ok. 

2. 5. 1.3  The  data  type  information  is  stored  in  the 
CDM  table  USER_DEF_DATA_TYPE .  with  a 
unique  object  number,  as  standard  for  this 
domain. 

2.5.2  For  a  non-standard  data  type,  the  data  type 
name  is  checked  as  in  step  2. 5. 1.1. 

2.5.2. 1  The  data  type  is  checked  as  in  2. 5. 1.2. 

2. 5. 2. 2  The  data  type  information  is  stored  in  the 
CDM  table  USERDEFDATATYPE  with  a  unique 
object  number  as  non-standard  (or  "USER") 
for  this  domain. 
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COM  TABLES  ACCESSED  -  ALTER  DOMAIN 
TABLE  NAME  SELECT  MODIFY 


ATTRI BUTE  CLAS S 
DATA  FIELD 
DAT A_ ITEM 
DATATYPE 
DOMAIN  CLASS 
USERDEFDATATYPE 
USER_DEF_DATA_TYPE 
USER  DEF  DATA  TYPE 
USER  DEF  DATA  TYPE 


N( VERACDT) 

N( VERDFDT) 

N( VERDIDT) 

N(VERTYP) 

N(VERDOM) 

S(UPDTDT) 
N(VERDT)  S(UPDIND) 
N(VERDTD) 

N(VERSDT) 


(S-SQL  N-NDML) 
INSERT  DELETE 


S(INSDT)  S(DELDT) 
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3. 2. 8. 4  ALTER  ENTITY  -  Alter  a  conceptual  entity 

A .  Funct i on : 

Alter  Entity  performs  the  following  functions: 

1.  add/drop  key  classes  for  the  entity  being  altered; 

2.  add/drop  owned  attributes  for  the  entity  being 
altered; 

3.  add/drop  associated  keywords  for  the  entity  class 
being  altered. 

B.  CDM  Requirements: 

1.  The  entity  to  be  altered  must  exist  in  the  current 
model . 

2.  If  owned  attributes  are  to  be  added,  the  attribute 
must  exist  in  the  current  model.  If  owned 
attributes  are  to  be  dropped,  they  must  be  owned  by 
the  entity  being  altered. 

3.  If  a  key  class  is  to  be  dropped,  it  must  be  a  key 
class  for  the  entity  being  altered. 

4.  If  a  keyword  is  to  be  dropped,  it  must  be 
associated  with  the  entity  being  altered. 

C.  Processing : 

1.  The  Alter  Entity  process  verifies  that  the  entity 
to  be  dropped  exists  in  the  current  model.  If  it 
does  not  exist,  an  error  is  issued  and  processing 
is  terminated. 

2.  If  key  classes  are  being  added,  a  new  occurrence  of 
key  class  is  added  to  the  entity.  A  new  occurrence 
of  attribute  use  class  is  created  for  each 
attribute  named  as  part  of  the  key,  if  one  does  not 
exist  for  the  entity.  A  new  occurrence  of  key 
class  members  is  created  for  the  entity  for  each 
attribute  named  in  the  key  class  clause. 

3.  If  owned  attributes  are  being  added  for  the  entity. 
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the  existence  of  the  attribute  class  is  determined 
within  the  current  model.  If  the  attribute  class 
does  not  exist,  an  error  is  issued  and  processing 
is  terminated.  If  they  do  exist,  each  attribute 
class  is  created  as  an  owned  attribute  class  and 
attribute  use  class  for  the  entity. 

4.  If  a  keyword  is  to  be  added  to  the  entity  class, 
the  keyword  table  is  searched  to  determine  whether 
the  keyword  exists.  If  it  does  not  exist,  the  new 
keyword  is  inserted  into  the  keyword  table.  The 
new  keyword  is  then  associated  with  the  entity 
class . 

5.  If  key  classes  are  being  dropped,  the  existence  of 
the  key  class  for  the  entity  being  altered  is 
determined.  If  it  does  exist,  the  key  class  and 
attributes  inherited  via  the  migrated  keys  and  key 
class  members  are  dropped.  If  the  key  class  being 
dropped  is  from  a  complete  relation,  the  complete 
relation  is  also  deleted. 

6.  If  owned  attributes  are  being  dropped,  they  are 
verified  to  determine  if  they  belong  to  the  entity 
being  altered.  If  they  belong  to  the  entity,  the 
owned  attribute  class  occurrence  and  the  attribute 
use  class  for  each  attribute  named  is  deleted  from 
the  entity  being  altered. 

7.  If  keywords  are  to  be  dropped,  a  check  is  performed 
to  verify  that  the  keyword  is  associated  with  the 
entity  being  altered.  If  so,  the  keyword 
association  is  deleted  from  the  entity. 
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CDM  TABLES  ACCESSED 

-  ALTER  ENTITY 

(S*=SQL,N=NDML) 

TABLE  NAME 

SELECT 

INSERT 

MODIFY  DELETE 

ATTRIBUTECLASS 

N(VERATT) 

ATTRIBUTENAME 

N(VERATT) 

ATTRI BUTEOSECL 

N(DELOAC) 

N(VERAUC) 

S(INSAUC) 

S ( DELAUCL ) 

COM  PLETERELAT I ON 

N(VERCRC) 

S(DELCMPR) 

ECKEYWORD 

ENTITY  CLASS 

ENTITY  NAME 

N(ADDKWE) 

N(VERENT) 

N(VERENT) 

S ( DELKWEC ) 

INHERITED_ATT_USE 

S(DELMIGK) 

S(DELIAUC) 

KEYWORD 

N(VERKW) 

S(INSKW> 

KEY  CLASS 

N(VERKC) 

S(INSKC) 

S(DELKC) 

KEY_CLASS_MEMBER 

N(DRPMGKM) 

S(INSKCM) 

S(DELKCM) 

OWNED_ATTRI BUTE 

N(DRPAC) 

N(VEROAC) 

S(INSOAC) 
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3. 2. 8. 5  ALTER  MAP  -  Modify  a  CS-IS  Mapping 
A.  Function: 

Alter  Map  allows  the  user  to  perform  the  following 
functions : 


1.  add  a  data  field  mapping  to  an  attribute  use  class 
(AUC)  to  data  field  map; 

2.  add  a  set  mapping  to  an  AUC  to  set  map; 

3.  drop  a  data  field  mapping  from  an  AUC  to  data  field 
map ; 

4.  drop  a  set  mapping  from  an  AUC  to  set  map; 

5.  change  a  secondary  AUC  to  data  field  mapping  to 
primary  and  the  previous  primary  mapping  to 
secondary ; 

6.  change  the  data  type  name  for  an  AUC  to  data  field 
mapping; 

7.  change  the  value  in  an  AUC  to  set  mapping; 

8.  add  a  set  mapping  to  a  relation  class  to  set  map; 

9.  drop  a  set  mapping  from  a  relation  class  to  set 
map. 

B.  CDM  Requirements: 

The  map  to  be  altered  must  exist  in  the  CDM.  In 
addition,  all  database  names,  record  names,  data  field 
names,  data  type  names,  and  set  names  referenced  must 
exist  in  the  CDM. 

C.  Processing : 

Different  rules  apply  depending  on  the  Alter  Map  option 
chosen . 

1.  For  an  AUC  to  data  field  map,  the  following  rules 
app 1 y : 


1 . 1  ALTER  ADD 
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1.1.1  The  AOC  must  not  have  been  previously  mapped 
to  a  set. 

1.1.2  The  ADC  must  not  have  been  previously  mapped 
to  a  data  field. 

1.1.3  If  no  data  type  name  is  entered,  the 
standard  data  type  for  the  ADC's  domain  is 
used. 

1.1.4  Only  one  primary  mapping  may  exist  for  an 
ADC . 

1.1.5  Multiple  secondary  mappings  may  exist  if 
there  is  a  pre-existing  primary  mapping. 

1.1.6  If  a  primary  or  secondary  mapping  is  not 
specified,  the  default  is  secondary. 

If  all  rules  are  obeyed,  a 

PRO JECT_DATA_F I ELD  entity  is  inserted  into 

the  CDMT 

1.2  ALTER  DROP 

1.2.1  If  secondary  ADC  to  data  field  mappings 
exist,  a  primary  ADC  to  data  field  map 
cannot  be  dropped. 

If  the  above  rule  is  obeyed,  a 

PRO JECT_DAT A_F I ELD  entity  is  deleted  from 

the  CDM . 

1.3  ALTER  ALTER 

No  special  validations  are  performed  for  the 
ALTER  ALTER  option  for  ADC  to  data  field 
mappings.  This  option  allows  a  secondary 
mapping  to  be  changed  to  primary  and  the 
previous  primary  mapping  to  secondary.  This 
option  also  allows  the  data  type  name  to  be 
changed.  In  both  cases,  PRO JECT_DATA_F I ELD 
entities  are  modified. 

2.0  For  an  ADC  to  set  map,  the  following  rules 
apply: 
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2.1  ALTER  ADD 

2.1.1  A  data  field  mapping  must  not  exist  for  the 
AUC. 

2.1.2  The  set  to  be  mapped  to  must  have  a  single 
record  type  for  its  members. 

2.1.3  The  set  to  be  mapped  to  must  not  have  been 
previously  mapped  from  a  relation  class  or 
another  ADC. 

2.1.4  All  AUC  to  set  maps  must  map  to  the  same 
database  for  a  particular  AUC. 

2.1.5  All  AUC  to  set  maps  must  contain  a  value 
which  must  be  unique  for  a  particular  AUC. 

2.1.6  All  sets  mapped  to  from  an  AUC  must  have  the 
same  reoord  type  as  its  owner. 

If  the  above  rules  are  obeyed,  an 
AUC_ST_MAPPING  entity  is  created. 

2 . 2  ALTER  DROP 

No  special  validations  are  performed  for  the 
ALTER  DROP  option  for  an  AUC  to  set  mapping. 

An  AUC_ST_MAPPING  entity  is  deleted. 

2 . 3  ALTER  ALTER 

The  AUC  value  must  be  unique  for  all  mappings 
from  a  particular  AUC. 

If  the  above  rule  is  obeyed,  an  AUCSTHAPPING 
entity  is  modified. 

3.0  For  a  relation  class  to  set  mapping,  the 
following  rules  apply: 


3.1.1  The  set  must  not  have  been  previously 
mapped . 
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3.1.2  The  member  reeord  name  must  be  specified  if 
the  set  being  mapped  to  is  a  multi-member 
set . 

If  the  above  rules  are  obeyed,  an 
RCBASEDRECSET  entity  is  created. 

3.2  ALTER  DROP 

No  special  validations  are  performed  for  the 
ALTER  DROP  option  for  a  relation  class  to  set 
mapping.  An  RCBASEDRECSET  entity  is 
deleted . 

3 . 3  ALTER  ALTER 

The  ALTER  ALTER  option  is  invalid  for  relation 
class  to  set  maps. 
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COM  Tables  Accessed  -  Alter  Map 


TABLE  NAME _ SELECT  MODIFY  INSERT 

ATTRIBOTECLASS  N(FINDDOM) 

ATTRIBUTE  USE  CL  N(VERAUC) 


AUC_ST_MAPPING  N(FNDASA)  S(ALTSMAP)  S(IHSAUCS) 

N(VOMAPS) 

N(VERASM) 

N(FNDASM) 

H(CHLTAUCV) 


DATABASE  N ( VERDB ) 

N(VERDF) 


DATA  FIELD 
ENTITYCLASS 
ENTITYNAME 
PROJECT  DATA  FIELD 


N(VERDF) 

N( VERENT) 

N(VERENT) 

N(PDFSRCH)  S(ALTSMAP)  S(INSPDF) 
N(VERPDF) 

N(GETMAPC) 


RCBASED  REC_SET  N( VERRCBS)  S(INSRCRS) 

N(VERRCMP) 

N(FNDRCM) 


RECORDSET  N( VERSMS ) 

N(VOMAPS) 


RECORD  TYPE 
RELATIONCLASS 
SET_TYPE_MEMBER 
USER  DEF  DATA  TYPE 


N(VERDF) 

N(VERRC) 

N( FND1MEM) 

N(VERSDT) 

N(VERDTD) 


DELETE 

SC DELI ASM) 


S(DELIPDF) 

S(DELIRCS) 
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3. 2. 8. 6  ALTER  MODEL  -  Creates  a  current  model  for  a  MDDL 

session  using  aodel ing  commands . 

A.  Function: 

Alter  Model  performs  the  following  functions: 

1.  updates  the  date  of  the  aodel  showing  the  model 
change  date; 

2.  creates  a  current  model  for  a  NDDL  session; 

3.  changes  the  status  of  the  model  to  ‘UNCHECKED". 

B.  CDM  Requ i remen t s : 

Alter  Model  requires  that  the  aodel  to  altered 

exists  in  the  CDM. 

C.  Processing: 

2.  The  Alter  Model  process  verifies  that  the  model 
was  created  previously.  If  the  aodel  does  not 
exist,  an  error  occurs  and  an  error  message  is 
issued. 

2.  The  model  being  altered  becomes  the  current 
aodel  for  a  NDDL  modeling  session  with  all 
subsequent  model  processing  identified  with  the 
model.  The  CDM  MODELCLASS  table  is  updated 
to  show  the  system  date  as  the  date  the  aodel 
was  updated  and  changes  the  model  status  to 
"UNCHECKED" . 


CPU  TABLES  ACCESSED  -  ALTER  MODEL 

NAME _ SELECT  MODIFY 

MODEL  CLASS  VERMOD(NDML) 
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(S-SQL.N-NDML) 
INSERT  DELETE 


MODEL  CLASS 


UPDMOD 
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3. 2. 8- 7  ALTER  RELATION  -  Alter  a  conceptual  relation  class. 

A.  Function: 

Alter  Relation  performs  any  or  all  of  the  following 

functions : 

1.  change  to  cardinality  of  an  existing  relation 
class : 

2.  migrate  the  key  class  of  the  independent  entity  to 
the  dependent  entity,  creating  a  complete  relation 
and  inherited  attribute  use  classes; 

3.  assign  new  tag  names  to  the  key  class  members 
migrated  to  the  dependent  entity; 

4.  associate  one  or  more  keywords  with  the  relation 
class ; 

5.  drop  the  key  class  from  the  relation  and  from  the 
dependent  entity  and  all  subsequent  entities  that 
inherited  the  key  class; 

6.  delete  any  empty  key  classes  that  results  from 
dropping  a  key  class  migration. 

B .  CDM  Requirements: 

1.  Key  class  for  independent  entity  must  exist. 

2.  Key  class  members  for  independent  entity  must  exist 

3.  An  attribute  use  class  for  each  key  class  member 
must  exist. 

4.  Relation  class  must  exist. 

5.  Independent  entity  class  must  exist. 

6.  Dependent  entity  class  must  exist. 

7.  If  a  key  class  is  to  be  migrated  to  the  dependent 
entity,  the  key  class  must  not  have  been  previously 
migrated  to  the  dependent  entity. 

8.  If  a  key  class  is  to  be  dropped  from  the  dependent 
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entity  and  all  subsequent  entities,  the  key  class 
must  have  been  previously  migrated. 

C.  Processing: 

Processing  varies  depending  on  the  options  chosen  by 
the  user.  If  an  error  is  detected,  processing 
continues  with  the  next  option  on  the  command. 

1 .  CARDINALITY 

Any  cardinalities  specified  replace  the  original 
values  established  when  the  relation  was  created, 
unless  an  error  is  detected,  a  warning  message  is 
generated  and  the  cardinality  defaults  to  its 
original  value. 

2 .  ADD  MIGRATES 

An  attribute  use  class  and  an  inherited  attribute 
use  class  for  the  dependent  entity  is  created  for 
each  key  class  member  migrated  to  the  dependent 
entity  class.  If  the  set  phrase  is  specified, 
TAG_NAME1  (the  independent  entity  is  tag  name)  is 
migrated  tc  the  dependent  entity  with  the  new  name 
TAG_NAME2.  A  complete  relation  class  occurrence  is 
created.  If  a  keyword  is  specified,  the  keyword  is 
created  in  the  CDM  if  it  doesn't  already  exist  and 
a  relation  class  keyword  occurrence  is  created. 

3 .  DROP  MIGRATES 

The  complete  relation  occurrence  for  the  relation 
class  is  deleted.  The  attribute  use  class,  and 
inherited  attribute  use  class  originally  created 
for  each  key  class  member  migrated  to  the  dependent 
entity  class  are  deleted.  In  addition,  the 
attribute  use  classes  and  inherited  attribute  use 
classes  created  for  each  key  class  member  migrated 
to  lower  level  dependent  entity  classes  are  also 
deleted.  Then  all  key  classes  and  complete 
relations  which  become  empty  due  to  the  deletion  of 
migrated  key  classes  members,  are  deleted. 

Finally,  any  text  descriptions  for  empty  key 
classes  are  deleted.  If  keywords  are  specified, 
the  relation  class  keyword  occurrence  are  also 
deleted . 
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CDM  TABLES  ACCESSED  -  ALTER  RELATION 


(S-SQL  N-NDML) 
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3. 2. 8. 8  CHECK  MODEL  -  Determines  if  the  model  conforms  to 
specified  IDEF1  rule 


A.  Function: 


The  check  model  performs  the  following  functions: 


1.  verifies  that  the  model  exists  in  the  CDM ; 

2.  verifies  that  the  model  has  one  or  more 
entities ; 

3.  verifies  that  the  entities  have  at  least  one 
attribute; 


4.  verifies  that  the  model  follows  the  specified 
IDEF1  rules  (see  rules  under  Processing); 

5.  updates  the  model  in  the  CDM  to  show  that  it  is 
a  "checked"  model  and  the  date  it  was  checked. 


B .  Requirements : 

The  check  model  process  requires  that  the  model 
exist  in  the  CDM.  (See  Rules  under  Processing). 

C.  Processing: 

The  check  model  process  determines  if  the  model 
follows  the  following  IDEF-1  rules. 

Rules : 


1.  no  non-specific  relations  are  allowed 
(independent  cardinality  greater  than  one). 

2.  no  incomplete  relation  classes,  (key  has  not 
been  migrated). 

3.  each  entity  must  have  at  least  one  attribute 
use  class. 

4.  each  owned  attribute  class  must  have  a  domain 
and  that  domain  must  have  a  standard  data  type. 

5.  a  key  class  must  be  defined  for  each  entity 
class . 
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6.  multiple  key  classes  of  an  entity  class  Bust 
not  be  subsets  of  one  another. 

7.  no  one  to  one  relations. 

8.  no  dependency  loops  e.g.  A->B->C->D->B. 

9.  at  least  one  entity  Bust  exist  in  the  sodel . 
The  following  rules  cannot  be  checked  for  the  nodel : 

1.  one  to  none  or  one  relationships  imply 
identical  keys. 

2.  key  uniqueness  throughout  the  model  is  not 
checked,  i.e.  no  two  entity  classes  may  have 
the  same  key  class  unless  they  are  related  to 
each  other  with  a  one  or  none  or  one  relation 

The  processing  verifies  the  existence  of  the 
sodel .  The  process  then  selects  each  entity 
class  belonging  to  the  sodel  and  checks  the 
relation  classes,  key  classes,  and  attributes 

Next  the  process  checks  the  hierarchical 
dependencies  both  up  and  down  to  determine  if 
there  are  any  dependency  loops  within  the 
model . 

If  all  rules  have  been  followed  the  CDM 
MODEL_CLASS  table  is  updated  to  reflect  the 
date  and  the  model  status  of  CHECKED. 
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CDM  TABLES  ACCESSED  -  CHECK  MODEL 


TABLE  NAME _ 

ATTRI BUTECLAS S 

ATTRIBUTEOSECL 

ENTITYCLASS 

ENTITY  NAME 

KEY  CLASS 

KE Y  CLAS  S  MEMBER 

MODEL  CLASS 

OWNED  ATTRIBUTE 


SELECT  MODIFY 

N(CHKATT) 

N(CHKATT) 

S(CHKLOOP) 

N(GETECS) 

N(RETRECP) 

N(GETECS) 

S(CHKKEYS) 

S(CHKKEYS) 

S(CHKLOOP) 

N(VERMOD) 

S(CHKATT) 

N(CHKREL) 

S(CHKLOOP) 

S ( TLOOPCK ) 

S  C  BLOOPCK ) 


(S-SQL.H-NDML) 
INSERT  UPDATE 


UPDMOD 


RELATION  CLASS 
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3. 2. 8. 9  COMBINE  ENTITY  -  Combine  two  conceptual  entities. 

A .  Function : 

Combine  Entity  performs  the  following  functions: 

1.  combine  two  entities  that  exist  either  within 
the  same  model  (intra-model)  or  between  two 
models  ( inter -model ) ; 

2.  generate  NDDL  commands  on  a  file  to  populate 
the  to-model  entity  with  the  attributes, 
relations,  aliases,  keywords,  keys,  key  class 
members  associated  with  the  from-model  entity. 


CDM  Rc 


lirements : 


1.  If  the  to-model  is  not  specified,  an  inter-model 
combine  is  assumed,  and  the  to-model  must  exist  in 
the  CDM. 


2.  If  the  to-model  and  from-model  are  specified,  both 
models  must  exist  in  the  CDM. 


3.  The  two  entities  to  be  combined  must  exist  in  the 
mode 1 ( s ) . 


Processing 


1.  If  it  is  an  intra-model  combine,  to-model  defaults 
to  the  from-model . 


2.  First,  verify  that  the  two  entities  to  be  combined 
exist  in  the  from-model  and  to-model.  Processing 
halts  if  any  of  the  verification  checks  fail.  The 
NDDL  commands  to  combine  the  from-entity  and 
to-entity  are  generated  in  a  user  defined  file. 
This  file  is  created  if  it  did  not  previously 
exist,  or  opened  and  appended  to  if  it  did  already 
exist . 


3.  Now  determine  if  a  relation  exists  between  the 

to-entity  and  from-entity.  If  one  does,  generate  a 
command  to  drop  this  relation.  Also,  if  it  is  an 
intra  model  combine  generate  a  command  to  delete 
the  from-entity. 
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4.  The  f rom-enti t ies  keys  and  key  class  members  are 
saved  in  a  temporary  key  list,  in  order  to  migrate 
the  keys  via  new  relations  that  will  be  created 
after  the  from-entity  has  been  combined  into  the 
to-entity . 

5.  Generate  an  "Alter  entity  and  owned  attributes..." 
for  all  the  attributes  that  belonged  to  the 
from-entity.  If  the  user  specified  that  he  wanted 
keywords,  aliases  and/or  descriptions,  NDDL. 
commands  are  generated  for  the  same.  The 
from-entity  name  is  generated  as  an  alias  for  the 
to-entity . 

6.  Next,  select  all  relations  in  the  from-model  where 
the  from-entity  is  the  dependent  entity  in  the 
relation.  If  this  from- independent  entity(s) 
exists  in  the  to-model ,  generate  Create  relation 
...  migrates .. .commands  for  the  same.  The  key 
class  that  was  inherited  via  this  relation  has  to 
be  generated  for  the  to-entity.  Generate  an  Alter 
Entity  add  key... for  the  inherited  key  class. 

7.  Next,  select  all  the  relations  in  the  from-model 
where  the  from-entity  is  the  independent  entity  in 
the  relation.  If  this  from-dependent  entity  exists 
in  the  to-model ,  generate  a  create 

relation. . .migrates .. .command  using  the  information 
stored  earlier  in  the  temporary  key  list. 

8.  Commands  are  also  generated  to  associate  keywords 
and  descriptions  with  the  relation  if  any  exist. 
Finally,  close  the  user  defined  file  at  the  end  of 
processing . 
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CDM  TABLES  ACCESSED  -  COMBINE  ENTITY  (S-SQL,  N-NDML) 

TABLE  NAME  _ SELECT  MODIFY  INSERT  DELETE 


ACKEYWORD 

N(GENAKW) 

ATTRIBUTECLASS 

N(CMBOA) 

N(VERATT) 

ATTRIBUTE  NAME 

N(CMBOA) 

N(VERATT) 

N(CMBACAL) 

ATTRI BUTE  USE  CL 

N(BLKCLl) 
S( SELIAUC) 

COMPLETE  RELATION 

N(VERRCC) 

DESC  TEXT 

N(GENDESC) 

DOMAINCLASS 

N(CMBOA) 

ECKEYWORD 

N(CMBEKW) 

N ( VERKWE ) 

ENTITYCLASS 

N(CMBALI) 
N(VERENT) 
N(BLKCLl) 
S( SELIAUC) 

ENTITY  NAME 

N(VERENT) 

N ( SELECNM ) 
N(CMBALI) 
N( VERALI ) 

INHERI TED_ ATTU S  E 

S( SELIAUC) 

KEYCLASS 

N(BLKCL1 ) 

KEYCLASSMEMBER 

N ( BLKCL 1 ) 

KEYWORD 

N(CMBRKW) 
N(CMBEKW) 
N( VERKWE) 
N(VERKWR) 
N(GENAKW) 
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CDM  TABLES  ACCESSED 

-  COMBINE 

ENTITY 

(S-SQL.  N-NDML) 

TABLE  NAME 

SELECT 

MODIFY 

INSERT  DELETE 

MODELCLASS  H(VERMOD) 


OWNEDATTRIBUTE  M(CMBOA) 

RCKEYWORD  N ( CMBRKW ) 

N(VERKVR) 

RELATION  CLASS  M(DEPFROM) 

N( INDFROM ) 

H(VERRC) 

M(SELRCNM) 
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3.2.8.10  COMPARE  MODEL  -  Compare  two  IDEF1  models. 

A.  Function: 

Compare  model  to  see  if  their  entity  name,  attribute 
name,  entity  keywords,  attribute  keywords  and  relation 
keywords  match  each  other. 

B.  CDM  Requirements: 

The  two  models  to  be  compared  must  exist. 

C.  Processing : 

1.  First,  verify  the  existence  of  both  models,  if 
either  of  these  two  models  does  not  exist,  flag  a 
user  error;  otherwise,  do  the  following: 

1.1  Compare  entity  classes  based  on  identical 
names . 

1.2  Compare  attribute  classes  based  on  identical 
names . 

1.3  Compare  entity  keywords  to  determine  if 
entities  from  both  models  use  the  same 
keyword . 

1.4  Compare  attribute  keywords  in  the  same  manner 
as  entities. 

1.5  Compare  relation  class  keywords. 

2.  For  each  successful  comparison  above,  a  message 
will  be  printed  out  to  indicate  a  match  is  found  in 
two  models . 
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COM  TABLES  ACCESSED  -  COMPARE  MODEL  (S-SQL 

TABLE  NAME  SELECT  MODIFY  INSERT 


ACKEYWORD 
ATTRIBUTECLASS 
ATTRIBUTE  NAME 
ENTITY  CLASS 


N(RETACKW) 

N(RETRACl) 

N(RETRACl) 

N(RETRECl) 

N(VERENT) 

N ( RETECKV ) 

N(RECKW2) 

N(RELKW) 


ENTITY  NAME 


N(RETRECl) 

N(VERENT) 

N(RETRECP) 


KEYWORD 


N(RETRCKW) 

N(RETECKW) 

N(RETACKW) 


MODEL  CLASS 
RC  KEYWORD 


N(VERMOD) 

N(RETRCKW) 

NCRRCKW2) 


RELATIONCLASS  N ( RETRCKW ) 

N( RRCKW2 ) 
N(GETRCID) 


N=NDML) 

DELETE 
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3.2.8.11  COPY  ATTRIBUTE  -  Copies  an  attribute  and  all 

associated  information  from  one  model  to  another  model 
(inter-model)  or  within  a  model  (intra-model). 

A.  Functions : 

Copy  Attribute  performs  the  following  functions: 

1.  verifies  that  the  model  specified  exists; 

2.  copies  an  attribute  within  a  model  or  to  another 
model ; 

3.  verifies  that  the  new  attribute  does  not  exist  in 
the  current  model ; 

4.  when  indicated,  copies  all  description  text, 
aliases,  and  keywords  related  to  the  attribute; 

5.  optionally,  places  the  created  NDDL  commands  in  a 
file  for  later  use; 

6.  optionally,  interactively  performs  the  intra-model 
copy. 

B.  CDM  Requ i remen t  s : 

The  Copy  Model  process  requires  that  the  from-model  and 

the  attribute  exist  in  the  CDM  database. 

C.  Processing : 

The  following  rules  apply  to  the  copy  attribute 

process : 

INTER-MODEL  Copy 

1.  The  from-model  must  be  specified  and  it  must  exist 
in  the  CDM  database. 

2.  The  command  must  include  the  file  clause  that  will 
contain  the  generated  NDDL  commands. 

INTRA-MODEL  Copy 

1.  The  second  or  new  attribute  clause  must  be 

specified  and  must  not  exist  in  the  current  model. 
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2.  The  file  clause  maybe  used. 

General  Rules 

1.  The  except  clause,  when  used,  indicates  what  items 
associated  with  the  attribute  are  not  be  copied. 

If  the  except  clause  is  omitted  all  keyword, 
aliases,  and  textual  descriptions  of  the  attribute 
are  copied. 

2.  The  process  verifies  that  the  current  model  exists 
in  the  CDM  database.  Additionally,  the  attribute 
to  be  copied  is  verified  and  its  domain  returned. 
If  either  attribute  or  model  is  not  found,  am 
error  message  is  issued  and  the  processing 
terminates . 

3.  The  processing  determines  whether  the  copy  is  to 
be  interactive  or  a  copy  to  a  file.  If  the 
process  is  interactive  only,  the  intra-model  copy 
may  be  processed. 

Interactive  Process: 

1.  The  interactive  process  verifies  that  the  new  or 
second  attribute  does  not  exist  in  the  current 
model.  If  the  attribute  does  not  exist,  the 
process  inserts  the  new  or  second  attribute  into 
the  ATTRIBUTECLASS  and  ATTRIBUTENAME  CDM  tables. 

2.  The  following  processing  depends  upon  the  use  of 
the  except  clause.  Any  entry  in  the  except  will 
exclude  that  entry  from  processing.  The  copied 
attribute  aliases  will  be  retrieved  and  copied  to 
the  new  attribute  in  the  ATTRI BUTE_NAME  CDM  table. 

3.  The  copied  attributes  keywords  will  be  retrieved 
and  copied  to  the  new  attribute  in  the  ACKEYWORD 
tables . 

4.  The  copied  attributes  textual  descriptions  will  be 
retrieved  and  copied  to  the  new  attribute  in  the 
DESCTEXT  table. 

COPY  TO  FILE  PROCESS 
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CDM  TABLES  ACCESSED  -  COPY  ATTRIBUTE  (S=SQL,  N=NDML) 

TABLE  NAME  SELECT  INSERT  MODIFY  DELETE 


AC  KEYWORD 

N(WRTACKW) 

N(GENAKW) 

S( INSKWAC) 

ATTR I BUTE  CLAS S 

N( VERACNM) 
N(VERATT) 

ATTRIBUTE  NAME 

N(VERATT) 

N( WRTALI ) 

N( VERACNM) 
N(FCOPATT) 

S( INSACNM ) 

DESC  TEXT 

N(GENDESC) 

S( WRTDESC) 

SC WRTDESC) 

DOMAIN  CLASS 

N( VERACNM) 

KEYWORD 

N(GENAKW) 

MODEL  CLASS 

N(VERMOD) 
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3.2.8.12  COPY  DESCRIPTION  -  Copy  CDM  object  descriptions. 

A.  Function: 

This  is  a  partial  description  copy.  Only  the 
description  lines  of  the  identified  description  type  of 
the  given  object  will  be  copied,  rather  than  all 
descr i pt i on  types . 


CDM  Rc 


i  i remen ts 


The  two  objects  identified  must  exist,  and  the 
description  type  and  the  description  of  the  object  must 
exist.  If  the  DESCTEXT  of  the  second  object  does  not 
exist,  the  DESC  TEXT  of  the  first  object  can  be  copied. 


Process ins 


1.  Verify  the  existence  of  the  model.  If  it  does  not 
exist,  flag  a  user  error. 


2.  Verify  the  existence  of  description  type.  If  it 
does  not  exist,  flag  a  user  error. 

3.  Verify  the  existence  of  both  models.  If  either  of 
these  two  models  does  not  exist,  flag  a  user  error. 


4.  Verify  the  existence  of  description  text  of  the 
first  object.  If  it  does  not  exist,  flag  a  user 
error . 


5.  Verify  the  non-existence  of  description  text  of  the 
second  object.  If  it  does  exist,  flag  a  user  error. 

6.  Finally,  copy  the  description  text  of  the  first 
object  to  the  second  object. 
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CDM  TABLES  ACCESSED  -  COPY  DESCRIPTION  S(S=SQL,  N-NDML) 


TABLE  NAME _ 

ATTRI BUTECLAS S 
DATA  BASE 
DATA  FIELD 
DATAITEM 
DESC  TEXT 

DESCRIPTIONTYPE 
DOMAIN  CLASS 
ENTITYCLASS 
KEYWORD 
MODELCLAS  S 
RECORDSET 
RECORD  TYPE 


SELECT _ MODIFY 

N(VERATT) 

N(VERDB) 

N( VERDFLD) 

N( VERDI ) 

N( VERDSTX) 

S( WRTDSC4 ) 

N( VERDSTP) 

N(VERDOM) 

N(VERENT) 

N(VERKW) 

N(VERMOD) 

N( VERRSET) 

N(VERRT) 


INSERT  DELETE 


S ( WRTDSC4 ) 
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3.2.8.13 

A. 


B. 

C. 


COPY  ENTITY  -  Copy  a  conceptual  entity  class. 
Function : 


COPY  ENTITY  allows  the  NDDL  user  to  perform  the 

following : 

1.  copy  an  entity  class  within  the  same  model,  giving 
it  a  different  name; 

2.  copy,  at  the  User's  discretion,  the  descriptions, 
aliases,  and  keywords  for  the  entity. 

3.  copy  an  entity  from  one  model  to  another , 
generating  the  NDDL  commands  that  the  user  would 
otherwise  have  to  type  in. 

4.  am  intra-model  copy  entity  will  allow  the  user  to 
generate  the  NDDL  commands  to  create  copies  of  all 
subordinate  entity  classes,  using  the  existing 
defintions  in  the  original  model. 

5.  am  intra-model  copy  entity  will  alternatively  allow 
the  user  to  generate  the  NDDL  commands  to  create 
copies  of  all  associated  relation  classes  of  the 
subject  entity. 

CDM  Requirements: 

The  entity  to  be  copied  must  previously  exist  in  the 

CDM.  The  entity  copied  to  must  not  exist. 

Processing : 

1.  Begin  processing  by  determining  if  the  copy  is 
inter-  or  intra-model.  If  a  model  name  is 
specified,  assume  intra-model  without  checking 
against  the  current  model.  This  will  allow  the 
user  to  use  COPY  ENTITY  to  generate  NDDL  for  the 
current  model.  The  from-model  is  verified.  The 
current  model  is  assumed  for  the  to-model .  Also 
the  intra-model  must  specify  a  new  entity  name. 

The  from  and  to  entity  names  are  verified. 

Finally,  perform  step  3,  to  perform  the  copy 
directly  if  an  intra-model  copy  was  determined  or 
an  inter-model  copy  without  the  selection  of 
STRUCTURE  or  RELATIONS.  Else  step  3  to  generate 
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NDDL  commands  shall  be  performed. 

For  an  internal  copy  entity,  the  database  is 

updated  directly. 

2.1  A  new  unique  number  is  obtained  and  the  entity 
and  its  primary  name  stored.  The  "TO"  entity 
name  will  be  made  primary. 

2.2  If  the  user  desired,  all  keywords  for  the  old 
entity  are  associated  with  the  new  entity. 

2.3  If  the  user  desired,  all  descriptions  from  the 
old  entity  are  copied  to  the  new  entity. 

2.4  If  the  user  desired,  all  aliases  for  the  old 
entity  are  copied. 

2.5  If  the  copy  entity  was  intra-model,  no 
attributes  can  be  copied  sinoe  they  are 
already  owned  (by  the  “FROM"  entity).  If  not. 
the  attributes  will  be  copied: 

2.5.1  For  each  attribute  owned  by  the  “FROM 
ent i ty : 

2. 5. 1.1  The  attribute  is  checked  in  the  “TO” 
model.  If  not  found,  obtain  a  new  number 
and  store  the  new  attribute  and  its  name 
as  primary. 

2. 5. 1.2  If  the  user  desired,  all  aliases  for  the 
original  attribute  all  copied  „o  the  new 
attribute . 

2.5. 1.3  If  the  user  desired,  all  keywords  for 
the  original  attribute  are  copied  to  the 
new  attribute. 

2. 5. 1.4  If  the  user  desired,  all  descriptions  for 
the  original  attribute  are  copied  to  the 
new  attribute. 

2. 5. 1.5  The  newly  created  attribute  can  be  stored 
as  owned  attributes  and  attribute  use 
classes  for  the  new  entity 
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2. 5. 1.6  All  key  classes  for  the  "FROM*  entity  can 
be  copied  to  the  new  entity.  The  key 
classes  of  the  attribute  being  copied, 
found  in  step  2.5.1.  are  stored  in  a 
table.  If  not  already  in  the  table,  a  new 
key  class  is  established  with  the  new 
attribute  as  its  key  class  member.  If  the 
key  class  was  on  the  list,  a  new  key  class 
member  is  created  for  the  new  attribute 
and  the  new  key  class  previously  created. 

3.  When  generating  NDDL  to  perform  the  COPY  ENTITY. 

determine  if  the  user  requested  “WITH  STRUCTURE"  or 

"WITH  RELATIONS". 

3.1  For  COPY  with  STRUCTURE,  generate  the  NDDL  to 
copy  the  entity  itself  (the  top  node).  Then: 

3.1.1  Generate  the  Create  Attribute  commands  for 
each  attribute  owned  by  the  entity  not 
already  found  in  the  "TO"  model.  Finally, 
generate  NDDL  to  Bake  the  attribute  owned  by 
the  new  entity.  Attribute  Descriptions  are 
"copied"  by  generating  DESCRIBE  coaaands  and 
attribute  aliases  are  "copied”  by  generating 
CREATE  ALIAS  commands .  When  copying  aliases 
the  target  model  is  checked  to  insure  the 
name  has  not  been  used  before. 

3.1.2  If  the  user  desired,  keywords  for  the  entity 
are  "copied"  by  adding  a  keyword  clause  to 
the  command . 

3.1.3.  If  the  user  desired,  aliases  are  copied  for 
the  entity  by  generating  CREATE  ALIAS 
commands . 

3.1.4  If  the  user  desired,  all  descriptions  for 
the  entity  are  copied  by  generating  DESCRIBE 
commands . 

3.1.5  The  key  classes  for  the  top  node  of  the 
structure  can  be  generated  next.  A  search 
of  the  key  classes  and  members  is  made  of 
the  original  entity  and  stored  in  a 
structure  The  original  EDNO,  KC  NO. 

KC  NAME.  KCM  TAG  NO  and  KCM  TAG  NAME  are 
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saved . 

3.1.6  An  Alter  Entity  couand  for  the  new  top  node 
can  now  be  generated  which  declares  each  of 
the  key  classes  and  its  members  found  in  the 
data  structure  stored  in  3.1.5. 

3.1.7  All  other  attributes  associated  with  the 
hierarchial  structure  of  entities  below  the 
original  top  node  are  ‘‘copied*  through 
generation  of  CREATE  ATTRIBUTE  commands  as 
described  in  3.2.1.  The  search  controlling 
this  generation  makes  use  of  a  recursive 
search  of  the  CDM's  RELATIONCLASS  table. 

3.1.8  All  other  entities  of  the  hierarchical 
structure  below  the  top  node  are  "copied*  by 
generating  the  appropriate  commands  as  was 
done  in  step  3.1.2  through  3.1.6.  A 
recursive  search  similar  to  the  one  of  step 
3.1.7  is  done.  For  each  primary  entity 
name  identified,  its  name  and  number  are 
stored  in  a  table. 

3. 1.8.1  The  owned  attributes  are  determined  and 
associated  with  the  new  entity  by 
generating  the  "owns"  clause. 

3. 1.8. 2  If  the  user  wishes  keywords  copied,  the 
"keyword"  clause  is  also  generated. 

3. 1.8. 3  For  the  alias  entity  names  found  in  the 
search  of  3.1.8  and  if  the  user  wishes 
aliases  copied,  then  CREATE  ALIAS  commands 
for  the  new  entity  are  generated. 

3. 1.8. 4  Finally,  if  the  user  desires,  all 
descriptions  for  the  new  entity  are  copied 
by  generating  DESCRIBE  commands. 

3.1.9  How  that  all  entities  have  been  created,  the 
Relation  Classes  connecting  the  structure 
can  be  generated.  This  must  be  done  in  a 
top  down  manner,  migrating  key  classes. 

After  all  attributes  are  migrated  into  an 
entity,  an  ALTER  Entity  can  be  generated  to 
create  the  new  key  classes  in  preparation 
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for  key  migration  to  the  next  level  down. 

3. 1.9.1  A  list  of  all  key  classes  and  their 
members  is  created  by  using  a  recursive 
search  of  the  CDM  Table  RELATIONCLASS . 

3. 1.9. 2  A  search  of  the  CDM  is  made  for  all 
relation  classes  "below*  the  top  node  in 
the  original  model.  The  results  of  this 
search  are  sorted  by  level,  relation  class 
number  and  dependent  entity.  Thus  all 
create  RELATIONS  for  one  level  can  be  done 
at  a  tine,  allowing  only  one  ALTER  ENTITY 
per  new  entity  and  insuring  that  all 
attributes  are  declared  as  key  before 
being  migrated. 

3. 1.9.3  A  search  is  made  of  the  CDM's 
COMPLETE  RELATION  table.  The  key 

class  number,  if  found,  is  used  to  search 
the  table  built  in  3. 1.9.1  and  a  MIGRATES 
clause  can  be  generated  for  the  CREATE 
RELATION  command.  The  SET  clause  is 
generated  and  for  each  attribute  which  is 
in  the  key  class,  its  original  name 
(independent)  and  new  name  (dependent)  are 
explicitly  generated. 

3. 1.9. 4  If  the  user  desired,  keywords  for  the 
relation  are  "copied”. 

3. 1.9. 5  If  the  user  desired,  descriptions  for  the 
relation  are  copied.  Aliases  for 
relations  are  not  supported  by  the  CDM. 

3. 1.9. 6  Finally,  the  ALTERENTITY  is  generated  to 
assign  its  key  classes,  like  step  3.1.5 
and  3.1.6. 

3.2  For  COPY  with  RELATIONS,  the  entity  itself  to 
be  copied  is  generated  as  was  done  in  step 
3.1.1  through  3.1.6. 

3.2.1  The  entities  and  the  relations  one  level 
below  the  entity  being  copied  are  also 
generated  as  done  in  3.2  above. 
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3.2.2  The  key  classes  are  generated  for  each 
entity  copied. 

3.2.3  Similar  to  3.2.1,  entities  and  relations  one 
level  above  the  entity  being  copied  are  also 
generated  as  done  in  3.2. 
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CDM  TABLES  ACCESSED  -  COPY  ENTITY 


(S-SQL  N-NDML) 


TABLE  NAME 


SELECT  MODIFY  INSERT  DELETE 


ACKEYWORD 

ATTRIBUTECLASS 

ATTRIBUTECLASS 

ATTRI BUTE  DSECL 

ATTRIBUTE  CLASS 

ATTR I BUTE  USE  CL 

ATTRI BUTECLASS 

ATTRI BUTEUSECL 

ATTRI BUTECLASS 

ATTRI BUTEUSECL 
ATTRIBUTE  USE  CL 


N(GENAKW) 

N(VERATT) 

N(CMBOA) 

N(BLKCLl) 

N( COPY AC) 

N( COPY AC) 

S(DEPATT) 

S(DPKCLST) 

N(GENOA) 

S(SELIAUC) 

NCSELIKEY) 


S(INSAC) 

S(INSAUC) 


ATTRI BUTENAME 
ATTRI BUTENAME 
ATTR I BUTENAME 
ATTRI BUTENAME 
ATTRIBUTE  NAME 


N(CMBACAL) 
N(CMBOA) 
S(DEPATT) 
N( GENOA) 
N(VERATT) 


COMPLETE  RELATION  N(VERRCC) 


DESC  TEXT 


N(GENDESC) 


S(WRTDESC) 


DOMAIN  CLASS 
DOMAIN  CLASS 

EC  KEYWORD 
EC  KEYWORD 
ECKEYWORD 
EC  KEYWORD 


N(DMBOA) 

S(DEPATT) 

N(CMBEKW) 
N(GENEKW) 
N( VERKWE ) 

N ( WRTECKW ) 


ENTITY  CLASS 
ENTITY  CLASS 
ENTITY  CLASS 
ENTITY  CLASS 


NCBLKCL1 ) 
N(CMBALI) 
N( COPY AC) 
S(SELIAUC) 
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-  COPY  ENTITY 


CDM  TABLES  ACCESSED 


TABLE  NAME 


ENTITYNAME 

ENTITYNAME 

ENTITYNAME 

ENTITYNAME 

INHERITED  ATT  USE 
INHERITED  ATT  USE 

KEY  CLASS 
KEY  CLASS 
KEY  CLASS 

KEY  CLASS  MEMBER 
KE Y  CLAS  S  MEMBER 
KEY  CLASSMEMBER 
KEY  CLASSMEMBER 

KEYWORD 

KEYWORD 

KEYWORD 

KEYWORD 

KEYWORD 

KEYWORD 

KEYWORD 

MODEL_CLASS 

OWNEDATTR I BUTE 
OWNED  ATTRIBUTE 
OWNED_ ATTR I BUTE 
OWNED  ATTRIBUTE 

RC  KEYWORD 
RC  KEYWORD 

RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 
RELATION  CLASS 


SELECT  MODIFY 

N( CM BALI) 
S(DEPENT) 
N(SELECNM) 

N ( WRTENAM ) 

S(SELIAUC) 

N(SELIKEY) 

N( BLKCL1 ) 

S(DPKCLST) 

N(KEYLOOK) 

N(BLKCLl) 

S  C  DPKCLST ) 
N(KEYLOOK) 
N(SELIKEY) 

N(CMBEKW) 

N(CMBRKW) 

N(GENEKW) 

N(GENRKW) 

N(VERKWE) 

N(VERKWR) 

N(GENAKW) 

N(VERMOD) 

N(CMBOA) 

N(COPYAC) 

S(DEPATT) 

N( GENOA) 

NCCMBRKW) 

N( VERKWR ) 

S ( BLRCKW 1 ) 

S(DEPATT) 

S(DEPENT) 

N( DEPFROM ) 
S(DEPREL) 

S( DPKCLST) 

N( INDFROM) 

N ( VERRC ) 


(S-SQL  N-NDML) 

INSERT  DELETE 

( INSECNM) 

S( INSKWEC) 

S(INSKC) 

S(INSKCM) 


S(INSOAC) 
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3.2.8.14 

A. 


B. 

C. 


COPY  MODEL  -  Generate  NDDL  commands  on  a  user  defined 
file  to  make  a  copy  of  an  existing  model. 

Function: 


Copy  Model  performs  the  following  functions: 

1.  create  a  new  model  containing  all  the  entities, 
owned  attributes,  inherited  attributes,  key 
classes,  key  class  members,  relations,  complete 
relations,  aliases,  keywords  and  descriptions  of 
the  model  being  copied; 

2.  generate  NDDL  commands  in  a  user  defined  file  to 
copy  a  model  in  proper  sequence  i.e.  by  level. 

CDM  Requirements: 

1.  The  model  to  be  copied  must  exist  in  the  CDM. 

2.  The  model  to  be  copied  into  should  not  exist. 

Processing: 

1.  If  the  model  to  copied  (the  f rom-model )  is  not 
specified,  the  model  name  defaults  to  the  current 
model .  The  copy  model  command  verifies  that  the 
f rom-model  exists,  and  that  the  new  model  to  be 
created  (the  to-model)  does  not  exist.  Processing 
halts  if  any  of  the  verification  checks  fail. 

2.  NDDL  commands  to  copy  the  f rom-model  are  generated 
on  a  user  defined  file.  If  the  named  file  does  not 
exist,  a  new  file  is  created  and  opened.  If  the 
file  does  exist,  the  generated  commands  are 
appended  to  the  file. 

3.  First,  create  all  the  attributes  contained  in  the 
frou-model,  along  with  their  associated  keywords, 
aliases  and  description  text. 

4.  Then,  create  all  the  entity  classes  contained  in 
the  from-model  along  with  associated  owned 
attributes,  keywords,  aliases,  and  description 
text . 

5.  Build  a  temporary  key  list  to  store  all  the  key 
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classes  and  key  class  members  for  each  entity. 

This  list  will  be  used  later  to  define  the  key  for 
the  entity  after  all  the  migrations  have  been 
determined  for  this  entity. 

6.  The  ORACLE  tree  search  feature  is  used  to  identify 
inheritance  at  all  lower  levels,  after  the  top  node 
is  identified.  The  model  being  copied  must  not 
contain  any  dependancy  loops.  Generate  an  Alter 
Entity  add  key...  command  for  the  top  node  in  this 
model's  tree  structure. 

7.  Another  temporary  list  is  built  to  store  all  the 
key  classes  of  the  dependent  entity  which  contain 
attributes  inherited  via  the  relation  for  each 
level  of  relations  in  the  f rom-model .  Both  these 
lists  are  used  to  generate  NDDL  statements 
necessary  to  oreate  the  relations.  For  each  level, 
migrate  the  keys,  and  add  keys  for  each  dependant 
entity  in  the  from-model .  NDDL  commands  are  also 
generated  for  keywords  and  descriptions  associated 
with  the  relation  classes. 

8.  Finally,  the  user  defined  file  is  closed. 
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CDM  TABLES  ACCESSED  -  COPY  MODEL 


TABLE  NAME _ 

AC-KEYWORD 
ATTR I  BUTECLAS  S 

ATTRIBUTE  NAME 

ATTRIBUTE  USECL 

COMPLETE  RELATION 
DESCTEXT 
DOMAINCLASS 
ECKEYWORD 
ENTITY  CLASS 


ENTITY  NAME 
INHERITED  ATT  USE 

KEYCLASS 

KEY_CLASS_MEMBER 

KEYWORD 

MODEL  CLASS 


SELECT  MODIFY 


N(GENAKW) 

N( GENOA) 
S(ALLATT) 

N( GENOA) 
S(ALLATT) 

N(BLKCLST) 
N( SELIKEY ) 

N(VERRCC) 

N(GENDESC) 

S(ALLATT) 

N(GENEKV) 

N ( BLKCLST ) 
S(ALLENT) 

S ( TOPNODE ) 
S(ALLREL) 
S(BLRCKC) 
S( SELIAUC) 

S(ALLENT) 

N( SELIKEY) 
S( SELIAUC) 

N( BLKCLST) 

N( BLKCLST) 
N( SELIKEY) 

N(GENAKW) 

N(GENEKV) 

N(GENRKW) 

S( TOPNODE) 


(S-SQL,  N-NDML) 
INSERT  DELETE 
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CDM  TABLES  ACCESSED  -  COPY  MODEL  (S-SQL,  N-NDML) 

TABLE  NAME _ SELECT  MODIFY  INSERT  DELETE 

S(ALLREL) 

S(BLRCKC) 

OWNED  ATTRIBUTE  N( GENOA) 

RC  KEYWORD  N ( GENRKW ) 

RELATION  CLASS  S(TOPNODE) 

S(ALLREL) 

S(BLRCKC) 
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3.2.8.15  CREATE  ALIAS  -  Create  an  alias  for  am  entity  or 
attribute 

A .  Funct ion: 


Create  Alias  performs  the  following  function: 

1.  allows  the  user  to  add  a  secondary  naae,  or  alias, 
for  any  attribute  or  entity  of  the  current  aodel . 

B .  CDM  Requirements : 

The  entity  or  attribute  naaed  in  the  coaaand  aust  exist 

in  the  user's  current  aodel . 

C.  Processing : 

1.  CREATE  ALIAS  shall  access  the  object  type  froa  the 
user  coaaand.  It  aust  be  either  ATTRIBUTE  or 
ENTITY.  The  coaaand  processor  aust  then  access  the 
user  entered  identifier  for  the  entity  attribute 
and  verify  its  presence  with  a  database  lookup. 

The  potential  new  alias  naae  is  also  verified  to 
aake  sure  it  has  not  already  been  used.  Finally, 
having  the  entity  attribute  nuaber  froa  the  first 
verification,  the  new  alias  naae  can  be  inserted. 
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CDM  TABLES  ACCESSED  -  CREATE  ALIAS  (S=SQL,N=NDML) 

TABLE  NAME _ SELECT  MODIFY  INSERT  DELETE 

ATTRIBUTE  CLASS  H(VERATT) 

ATTRIBUTE  NAME  N(VERATT)  S(INSACNM) 

ENTITY  CLASS  N(VERENT) 

N(VERENT) 


ENTITY  NAME 


S( INSECNM) 
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3.2.8.16  CREATE  ATTRIBUTE  -  Create  a  conceptual  attribute 

A.  Function: 


Create  Attribute  performs  the  following  functions: 

1.  create  an  attribute  for  a  model; 

2.  assign  a  domain  for  the  attribute; 

3.  add  keywords  to  an  attribute. 

B .  CDM  Requ i rement  s : 

A  current  model  must  be  established. 

C.  Processing: 

1.  If  a  domain  is  specified,  the  Create  Attribute 
command  verifies  the  existence  of  the  domain  to 
which  the  attribute  is  being  assigned.  If  the 
domain  is  not  specified,  the  domain  will  default  to 
zero  or  undefined. 

2.  Next,  a  check  is  performed  to  verify  that  the 
attribute  does  not  previously  exist  in  the  model. 
Then  the  attribute  is  inserted  into  the 
ATTRIBUTECLASS  and  ATTRIBUTENAME  tables.  This 
attribute  is  created  as  the  Primary  attribute. 

3.  If  keywords  are  to  be  added  to  the  attribute, 
verify  that  the  keyword  has  not  previously  been 
assigned  to  the  attribute.  Keyword  references  are 
then  created  for  the  attribute  by  inserting  into 
the  ACKEYWORD  table.  Also,  the  keyword  will  be 
inserted  into  the  KEYWORD  table  if  it  did  not 
previously  exist. 

4  Processing  halts  if  any  of  the  verification  checks 
fail 


* 
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COM  TABLES  ACCESSED  -  CREATE  ATTRIBUTE  ( S-8QL.  ■-■DHL) 

TABLE  NAME  SELECT  MODI FT  INSERT  DELETE 


ACKEYWORD 

N(ADDKWA) 

S( INSKWAC ) 

ATTRIBUTE  CLASS 

H(VERATT) 

S(INSAC) 

ATTRIBUTENAME 

N(VERATT) 

S( INSACNM ) 

DOMAIN  CLASS 

N(VERDOM) 

ECKEYWORD 

N(ADDKWE) 

S( INSKWEC ) 

KEYWORD 

N(VERKW) 

S( INSKW) 

RC  KEYWORD 

N( ADDKWR) 

S( INSKWRC) 
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3  2  8  17  OlATE  DOMAIN  -  CrMt«  a  douin 

A  Fund  I  on 

Croat*  Dona in  perforns  th*  following  functions: 

1  adds  a  new  dona in  to  the  systen. 

2  associatts  a  standard  data  typ*  with  th*  n«w 
doaain . 

3  associates  optional  us*r-d*fin*d  data  types  with 
th*  n*w  dona in 

l  CPU  Sequirenent s 

1  Th*  dona in  nust  not  previously  exist  in  th*  systen 

2  Th*  standard  data  typ*  for  th*  n*w  dona in  nust  b* 
specified  in  th*  first  data  typ*  claus* 

3  Additional  data  types  nay  be  specified  in 
sabsefuent  data  type  clauses  These  data- types  are 
considered  user -deft end  data  types  for  th*  new 
dona in 

C  Process  inf 

1  Creats  Dona  in  verifies  that  th*  dona  in  to  b*  added 
does  not  exist  in  th*  systen  Then  th*  new  dona  in 
is  inserted  into  th*  DOMAIN  CLASS  table 

2  Th*  data  typ*  specified  for  th*  standard  or 

us*r  defined  DATA  TYPE  NAME  is  verified  as  a  legal 
data  type  and  the  aenfeer  of  declnals  if 
specified  nust  not  exceed  th*  naxteun  field  length 
of  DATA  TYPE  NAME  Th*  DATA  TYPE  NAME  is  then 
inserted  into  USES  DEP  LATA  TYPE  tables  as  a 
standard  or  user  defined  data  type  for  th*  new 
dona i n 
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CDH  TABLES  ACCESSED  -  CREATE  DOMAIN  ( S-SQL , N-NDML) 

TABLE  NAME _ SELECT  MODIFY  INSERT  DELETE 

DOMAIMCLASS  M(VERDOM)  S(IHSDOM) 

USER  DEF  DATA_TTPE  M( VERSDT)  S(IMSDT) 

M(VERDT) 

M(VEROTD) 

DATA  TYPE  M(VERTYP) 
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3.2.8.18  CREATE  ENTITY  -  Create  a  Conceptual  Entity  Class 

A.  Function: 

CREATE  ENTITY  will  allow  the  NDDL  user  to  perfora  the 
following  functions: 

1.  create  a  new  entity  class  for  the  current  aodel; 

2.  associate  attributes  as  owned  attributes  for  this 
entity: 

3.  define  key  classes  of  the  owned  attributes  only, 
(unowned  attributes  must  be  Bigrated  to  the  entity 
by  use  of  ihe  CREATE  or  ALTER  RELATION  conaands ; 

4.  associate  keywords  with  the  entity. 

B.  COM  Requireaents : 

The  entity  being  created  aust  not  previously  be  found 
in  the  current  aodel .  Any  attribute  referenced  aust 
already  be  defined  for  the  current  aodel  and  aust  not 
be  previously  owned  by  any  entity. 

C.  Processing : 

1.  First  the  entity  itself  is  created.  The  naae  is 
accessed  froa  the  coaaand  and  database  lookup 
verifies  that  it  is  not  already  present.  If  not 
found,  the  entity  class  is  assigned  a  unique  nuaber 
and  stored  and  the  user  entered  naae  is  stored  as 
the  entity's  prlaary  or  preferred  naae.  not  an 

al las . 

2.  Any  user  specified  attributes  are  then  processed 
Each  attribute  naae  aust  be  found  in  the  current 
aodel  and  also  verified  not  to  be  owned  by  any 
other  entity  in  the  aodel.  If  these  conditions  are 
net.  the  attribute  can  be  associated  with  the 
entity  by  storing  an  occurrence  of  OWNED  ATTRIBUTE 
Finally,  a  unique  tag  nuaber  is  obtained,  and  the 
attribute  is  also  stored  as  an  ATTRIBUTE  USE  CLASS 
of  this  entity. 


3.  When  the  user  has  specified  any  key  classes  to  be 
defined  for  this  entity,  the  user  aay  oait  the 
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attribute  nun  for  the  key  class.  Therefore,  the 
key  class  ease  aay  bo  taken  as  tko  attribute  naae 
if  none  follows  the  -  sign.  For  each  key  class 
specified  the  prograa  oust: 


3.1  Verify  the  key  olass 
this  entity. 


was  not  used  for 


3.2  Obtain  a  unique  nuaber  for  the  key  class. 

3.3  Store  a  key  class  occurrence  for  the  entity 
first  created 


3.4  Process  each  attribute 
ourrent  key  class. 


specified  for  the 


3.4.1  Deteraine  if  the  attribute  has  already  been 
associated  with  the  entity  as  an  ATTRIBUTE 
OSS  CLASS. 


3.4.2  If  it  had  not.  an  atteapt  is  aade  to  aake 
the  attribute  owned  by  the  entity  as 
specified  in  step  2  above 

3.4  3  Finally,  an  occurrence  of  1ST  CLASS  SENSES 
can  be  stored 

Finally,  aay  keywords  specified  by  the  user  can  be 

related  to  the  entity  first  created  For  each 

keyword  entered 

4  1  The  keyword  is  verified  in  the  table  of 
keywords  ( independent  of  eodel ) 

42  If  the  keyword  is  new.  then  a  unique  nuaber 
for  the  keyword  is  obtained  and  a  keyword 
occurrence  is  stored 

4  3  Finally,  the  keyword  to  entity  cross  reference 
is  (EC  KEYWORD)  stored,  relating  the  keyword 
to  the  entity  just  created 
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COM  TABLES  ACCESSED  -  CREATE  ENTITY 


TABLE  BABE 


NODirr 


(S-SQL.  N-NDNL) 
IBSEBT  DELETE 


ATTRI BUTECLA8S 

B(VEBATT) 

ATTBX BOTE  BANE 

B(VEBATT) 

ATTBIBOTE  USE  CL 

N(  VERA  tlC ) 

B(  INSAUC) 

EC  KEYVORD 

H( ADOKVE ) 

S( INSKVEC  ) 

ENTITY  CLASS 

B( VEBENTC ) 

S(  INSEC) 

ENTITY  NAME 

B( VEBENT ) 

S( IB8ECNM  ) 

EETVOBD 

B(VSBEV) 

S(  INBEV) 

KEY  CLASS 

B(VEBEC) 

S( INSET) 

KEY  CLASS  MEMBER 

S(  INSKCM) 

OWNED  ATTBIBOTE 

H(  VEBOAC > 

S(  IHSOAC  ) 

v 
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3.2.8.19  CREATE  MAP  -  Create  CS-IS  mapping 
A .  Function : 

The  CREATE  HAP  command  allows  the  user  to  map  an 
attribute  use  class  (AUC)  to  a  data  field  or  set.  or 
from  a  RELATION  CLASS  to  a  set. 


il  remen  ts 


The  AUC  or  the  relation  class  from  which  you  map  and 
any  or  all  of  the  following  whioh  are  to  be  mapped  to: 
the  database,  record  name .  data  field  name,  data  type 
name,  set  name  and  member  record  name;  must  all  exist 
in  the  CDH 


C  Processing : 

Processing  differs  depending  on  the  type  of  napping 
attempted 

1  Por  an  AOC-to-data  field  mapping,  the  following 
rules  apply: 


1  l  The  AUC  must  not  have  previously  been  mapped 
to  a  set 


1  2  The  AUC  must  not  have  previously  been  mapped 
to  a  data  field 


13  If  a  data  type  name  is  not  entered,  the 

standard  data  type  for  the  AUC  s  domain  is 
used 


14  Only  one  primary  mapping  may  exist  for  an  AUC 

l  5  Multiple  secondary  Mappings  may  exist  if  there 
is  a  pre  existing  primary  mapping 


1  f>  if  the  primary  or  secondary  mapping  is  not 
specified  the  default  is  primary 

If  all  rules  are  obeyed,  a  PROJECT  DATA  FIELD 
entity  is  inserted  into  the  COM 

JL  For  an  AUC  to  set  mapping,  the  following  rules 
apply 
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2.1  A  data  field  map  must  not  exist  for  the  AUC. 

2.2  The  set  to  be  mapped  to  must  have  a  single 
record  type  for  its  members. 

2.3  The  set  to  be  mapped  to  must  not  previously 
have  been  mapped  from  a  relation  class  or 
another  AUC. 

2.4  All  AUC  to  set  maps  must  map  to  the  same 
database  for  a  particular  AUC. 

2.3  All  AUC  to  set  maps  must  contain  a  value  which 
must  be  unique  for  a  particular  AUC. 

2.6  All  mapped  to  sets  from  a  AUC  must  have  the 
same  record  type  as  its  owner. 

If  all  rules  are  obeyed,  an  AUCSTMAPPIMG  entity 
is  inserted  into  the  CDM. 

For  a  relation-class-to-set-mapping,  the  following 
rules  apply: 

3.1  There  must  be  no  previous  mappings  to  the  set. 

3.2  The  member  record  name  is  required  if  the  set 
mapped  to  contains  member  records  of  more  than 
one  type. 

If  all  rules  are  obeyed,  an  RC  BASED  REC  SET  entity 
is  inserted  into  the  CDM. 

A  relation  class  to  data  field  mapping  is 
meaningless  and  therefore  illegal 
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COM  TABLES  ACCESSED  -  CREATE  MAP  (S-SQL,  N-NDHL ) 

TABLE  NAME  SELECT  MODIFY  INSERT  DELETE 


ATTRI BUTE  CLASS 

M(FINDDOM) 

ATTRI BUTE  USE  CL 

H(VERAUC) 

AUC  ST  MAPPING 

M(VOMAPS) 

N(FNDASA) 

N(VERASM) 

S( INSAUCS ) 

DATA  BASE 

M(VERDB) 

N(VERDF) 

DATA  FIELD 

M(VERDF) 

ENTITYCLASS 

N(VEREMT) 

PROJECT  DATA  F I ELD 

M( PDFSRCH) 

M ( VERPDF ) 

S(INSPDF) 

RC  BASED  REC  SET 

M( VERRCBS) 
N(VERRCMP) 

S( INSRCRS ) 

RECORD  SET 

M(VOMAPS) 

N(VERSMS) 

RECORD  TYPE 

N(VERDF) 

RELATION  CLASS 

M(VERRC) 

SET  TYPE  MEMBER 

N( FND1MEM ) 

USER  DEFDATA  TYPE 

N(VERSDT) 

N( VERDTD) 
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3.2.8.20  CREATE  MODEL  -  Create  a  new  IDEF1  aodel 

A.  Function: 


A  new  aodel  is  created  as  unchecked  in  the  systea. 

B.  CDM  Reguireaents : 

The  aodel  to  be  created  Bust  exist  in  the  CDM . 

C.  Processing: 

1.  First,  verify  whether  the  Bodel  to  be  created 

exists  in  the  systea.  If  it  does,  flag  an  error 
otherwise,  obtain  a  aodel  nuaber  for  the  aodel 
naae . 


2.  Store  the  aodel  nuaber,  aodel  naae  into  the  CDM 
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CDM  TABLES  ACCESSED  -  CREATE  MODEL 


(S-SQL.  N-NDML) 


TABLE  NAME 


MODEL  CLASS 


SELECT  MODIFY 
M(VERMOD) 


INSERT  DELETE 

S(INSMOD) 
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3.2.8.21  CREATE  RELATION  -  Create  a  relation  class 

A .  Function: 

Create  Relation  performs  the  following  functions: 

1.  create  a  relation  class  for  user  entered 
independent  and  dependent  entity  classes; 

2.  create  associated  keywords  for  the  relation  class; 

3.  migrate  a  key  class  from  the  independent  entity 
class  to  the  dependent  entity  class. 

B .  CPU  Requirements: 

The  independent  and  dependent  entity  class  must  exist 

in  the  current  model.  If  the  migrates  clause  is 

present,  the  key  class  for  the  independent  entity  must 

exist  in  the  current  model. 

C.  Processing: 

1 .  The  Create  Relation  process  verifies  that  both  the 
independent  and  dependent  entity  class  exist  in  the 
current  model.  If  both  do  not  exist,  an  error  is 
issued  and  processing  is  terminated.  A  check  is 
made  to  determine  if  the  relation  class  to  be 
created  already  exists  between  the  user  entered 
entity  classes.  If  one  does  exist,  as  above,  an 
error  is  issued  and  processing  is  terminated. 

2.  Next,  the  process  validates  the  cardinality  of  the 
relation  class  to  be  created.  If  a  cardinality  is 
omitted  by  the  user,  the  relation  is  assigned  a 
default  value.  The  default  for  the  independent 
cardinality  is  a  value  of  one.  The  default  for  the 
dependent  cardinality  is  a  value  of  zero  for  the 
left  dependent  cardinality  and  a  value  of  99  for 
the  right  dependent  cardinality. 

3  If  the  migrates  clause  is  entered,  the  existence  of 
the  key  class  for  the  independent  entity  is 
determined.  If  the  key  class  does  not  exist,  an 
error  is  issued  and  processing  is  terminated.  An 
attribute  use  class  and  an  inherited  attribute  use 
class  for  the  dependent  entity  class  is  created  for 
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each  key  class  member  of  the  independent  entity 
class  migrated  to  the  dependent  entity  class.  If 
the  set  phrase  is  specified,  TAGNAME2  (the 
independent  entities  tag  name)  is  migrated  with  the 
new  name  of  TAGNAMEl . 

If  a  keyword  is  to  be  added  to  the  relation  class, 
the  keyword  table  is  searched  to  determine  whether 
the  keyword  exists.  If  it  does  not  exist,  the  new 
keyword  is  inserted  into  the  keyword  table.  The 
new  keyword  is  then  associated  with  the  relation 
class . 


4. 


2/2 
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COM  TABLES  ACCESSED 

TAME  —I _ 

ATTA1B0TS  OBB  CL 

OOMPLSTB  ABLATIO* 
IBSEAITED  ATT  OSE 
KEY  CLASS 
UT  CLASS  NBMBBA 
EETVOAD 
BC  EETVOAD 
ABLATION  CLASS 


CABATE  ABLATION 

SELECT  MODI  FT 

B( VBAAOC ) 

B( AHBUG) 

A( VBAAOC ) 

B( VBABC ) 

B( ADONIC ) 

B(AOOKVA) 

A(  VBABC) 


( 8-SQL . A-BDHL ) 

1 ASSET  DELETE 

S(  IBSAOC) 

S( IBSCAC) 

8(  I  MS  I  ADC  ) 


S( 1BSSV ) 

8( IMSBVBC ) 
S( I MSEC ) 
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S.2.8.22  CKEATE  VIEW  -  Crtat*  an  «xUml  sch. 

aappiafc  to  the  conceptual  scheaa. 

A.  Function: 


view  and 


Create  a  view  of  the  entity  class  and  relation  class 
existing  in  the  conceptual  sohena  of  the  Cosuaon  Data 
Model . 


The  following  elenents  nust  exist  in  the  CDM 

1.  independent  entities  specified; 

2.  dependent  entities  specified; 


relation  di 


entity  classes  of  the  view; 

data  iteas  defined  and  attribute  use  class  of  the 
entities  Bust  be  froa  the  saae  doaain. 


C.  Process  ini 


1.  Verify  if  the  view  to  be  created  already  exists.  If 
it  does,  flag  a  user  error. 

2.  Obtain  a  unique  number  for  the  view  to  be  created. 

3.  Insert  the  view  naae  and  view  number  into  the  CDM . 

4.  Construct  an  in-code  tables  fron  the  user 
inforaation  in  the  create  view  command  syntax. 

3.  Examine  the  from  in-code  table,  if  empty,  indicates 
only  one  entity  class  selected.  Fill  in  with  the 
first  entity  naae  from  the  select  clause.  If  an  * 
was  entered  in  the  select  clause,  its  an  error 
since  there  is  no  way  of  knowing  what  the  entity 
class  should  be. 

6.  If  only  one  entity  class  has  been  entered  in  the 
select  clause,  the  following  functions  must  be 
performed : 
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6.1 

Verify  antity. 

6.2 

Verify  that  data  items 

and  tags 

are  from  the 

same  domain  class. 

6.3 

Insert  view  number  and 

tag  name 

into  DAT A_ ITEM 

and  POOJECT__DATA_XTEM ,  if  the  data  item  list 
is  blank. 

7.  If  nultipla  antity  olass  is  in  tha  salaot  clause, 
the  following  functions  mist  be  performed: 

7.1  Expand  abbreviations  to  antity  class  naaes  in 
salact  and  vhare  olausas. 

7.2  Verify  each  relation  in  the  where  clause. 

7.3  Verify  antity  and  doaain. 

7.4  Store  SEC  RC. 
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CPU  TABUS  ACCESSED  -  CREATE  VIET 


TABLE  BAME _ 

ATTRIBUTECLA8S 

ATTRIBUTEUSICL 

DATAITEM 
EMTITY  CLASS 
PRO JECTDATA  I TEM 
RELATIOH_CLASS 
SEC 

SECRCCOMPOKEKT 
USER  DEF  DATA  TYPE 


SELECT  MODIFY 


B(ALLVIEV) 

R(GETDOM) 

R(ALLVIEV) 

XGETDOM) 


K(  VERE1VT) 

X VERRC) 
XVERVIEV) 

R(VERSDT) 

R(VERDTD) 


(8-8QL,  H-MDML) 
IWSERT  DELETE 


S( IHSD1 ) 

S( I MS PD 1 ) 

S(IHSSEC) 

S(IMSSECR) 
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B. 

C. 
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DMPIB1  DATABASE  -  Desoribe  the  definition  of  n 
database  to  the  COM  Internal  schema . 

Function: 


The  ooeennd  defines  n  database  to  the  COM. 

COM  Boqulrensnts : 

The  database  to  be  defined  eust  not  exist  in  the  COM. 

Process  inf 

1.  Verify  the  existence  of  the  database  to  be  defined 

if  it  exists  flag  a  user  error. 

2.  Obtain  a  unique  number  for  the  database. 

3.  Insert  the  database  entity  occurrence. 

4.  If  DBMS  is  OBACLS: 

4.1  Insert  the  password  entity  occurrence  of  the 

database . 

5.  If  DBMS  is  TOTAL: 

8.1  Verify  the  existence  of  the  area  of  the 
database.  If  it  already  exists,  flag  a  user 
error . 

8.2  Insert  the  area  entity  occurrence  of  the 
database  l1!)  the  COM. 

6.  If  the  DBMS  is  IMS: 

6.1  Check  if  the  start  position  and  feedback 
length  are  provided  in  the  connand. 

6.2  If  they  are  not  in  the  command,  flag  a  user 
error . 

6.3  Verify  the  existence  of  the  PSB  of  the  IMS 
database.  If  it  already  exists,  flag  a  user 
error;  otherwise,  insert  the  PSB  entity 
occurrence  and  the  PCB  entity  occurrence. 
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7.  If  DM8  is  0004STL: 

7 . 1  Insert  lh«  ioh—  occurrence  of  the  OODASTL 

database. 

7.2  Verify  the  existence  of  the  area  of  the 
OOOASTL  database.  If  it  already  exists,  flag 
a  user  error.  Otherwise,  insert  the  area 
occurrence . 
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COM  TABLES  ACCESSED 

TABLE  BANE 

-  DEFINE  DATABASE 

SELECT  MODIFY 

(S-SQL.W-NDML) 

INSERT  DELETE 

DBP AS SWORD 

S(INSPWRD) 

DATABASE 

N(VERDB) 

S(INSDB) 

DATABASEAREA 

N(VERAREA) 

S( INSAREA) 

PSB 

N(VERPSB) 

S(INSPSB) 

PSBPC 

S(INSPCB) 

REUSABLENUMBER 

S(NRGET) 

SCHEMA  NAMES 

SCIMSSDT) 
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3.2.8.24  DEFINE  RECORD  -  Creates  a  Record  Type/Table/Segment 
for  a  previously  defined  database/ PCB 

A.  Function: 


Define  Record  performs  the  following  functions: 

1.  verifies  that  the  database  exists; 

2.  verifies  that  the  record  has  not  previously  been 
defined; 

3.  inserts  the  record  into  the  CDM  database; 

4.  if  the  database  is  CODASYL ,  the  process  verifies 
that  the  database  area  already  exists  and  inserts 
the  record  into  the  CDM  database  area  of 
assignment ; 

5.  if  the  DBMS  is  IMS,  the  process  inserts  the 
I MS_SEGMENT_S I ZE  and  the  SEGMENT_DATA_FIELD ; 

6.  if  the  DBMS  is  CODASYL  or  TOTAL,  the  command 
inserts  the  record  key  and  the  record  key  members. 

B.  CDM  Requirements: 

This  process  requires  a  previously  defined  database. 

C.  Processing: 

1.  Define  Record/Table/ Segment  verifies  that  the 
database  exists  in  the  CDM  and  that  *he  record  has 
not  been  previously  defined  for  that  database.  If 
the  database  exists  and  the  record  has  not  been 
defined,  the  record  is  inserted  in  the  CDM 
database . 

2.  CODASYL  DBMS  -  The  process  verifies  the  database 
area  for  the  database  and  then  inserts  the  record 
into  the  CDM  DB  area  assignment. 

3.  IMS  DBMS  -  The  process  inserts  the  record  segment 
size  in  the  CDM  IMS-Segment  size  table. 

4.  ALL  DBMS  -  The  process  inserts  each  specified  data 
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field  for  the  record  into  the  CDM  data  field  table. 
Additionally,  for  IMS  DBMS  the  data  field  inserted 
in  the  CDM  Segaent  data  field. 

5.  TOTAL  8  CODASYL  DBMS  -  If  record  key  inforaation 
has  been  specified,  the  process  verifies  that  the 
record  key  has  not  been  previously  defined. 

6.  If  not,  a  -  key  is  created  for  the  newly  defined 
record.  A  check  is  made  to  verify  that  each  data 
field  sectioned  as  a  key  aeaber  has  been  defined  as 
a  data  field  for  this  record.  Each  data  field  is 
then  created  as  a  record  key  aeaber. 
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CDM  TABLES  ACCESSED  -  DEFINE  RECORD 


( 


TABLE  NAME _ 

DATABASE 

DATABASEAREA 

DATAFIELD 

I MSSEGMENTS I ZE 

RECORDKEY 

RECORDKEY 

RECORD_KEY_MEMBER 

RECORDTYPE 

SEGMENT  DATA  FIELD 


SELECT  INSERT  MODIFY 


N(VERDBAS) 

N( VERAREA)  S(INSDAA) 


S( INSDFLD) 

S(INSISS) 

N(VERRX) 

S( IHSRKEY ) 

N(VERRKM) 

S(INSRKM) 

N(VERRT) 

S( INSRTYP) 

S( INSSDFL) 

S-SQL,  N-NDML) 
DELETE 
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5.2.8.25  DEFINE  SET  -  define  or  intern&l  set /path  for  OODASYL , 
TOTAL  and  IMS  DBMS's 

A .  Function : 


Define  set  performs  the  following  functions: 

1.  create  a  set/path  for  a  OODASYL  (VAX-11.  IDMS. 

IDS).  IMS  or  TOTAL  DBMS; 

2.  allow  a  set  between  owner  and  Multiple  nenbers  for 
CODAS YL.  but  only  single  member  for  other  DBMS. 

B.  CDM  Requirements: 

The  database  aust  be  established  during  the  session. 

The  owner  and  aeaber  record  types  aust  exist.  If 

creating  a  set  for  a  TOTAL  DBMS,  the  data  field  froa 

the  variable  record  aust  exist. 

C.  Processing: 

1.  Define  Set  verifies  the  existence  of  the 
database/ PCB  in  which  the  set  is  to  be  created.  If 
the  database  is  not  specified,  it  defaults  to  the 
database  established  during  the  current  session. 

2.  Next,  a  check  is  performed  to  verify  that  the  set 
to  be  created  does  not  exist.  For  an  IMS  database, 
the  path  name  is  derived  by  combining  the  owner 
record  and  member  record  names. 

3.  For  a  TOTAL  or  IMS  database,  verify  that  the  owner 
and  member  records  have  previously  been  defined. 

In  addition,  verify  that  the  data  field  of  the 
variable  (member)  record  to  which  the  set  is  to  be 
linked,  has  also  been  defined.  The  set  information 
is  then  inserted  into  the  DF_SET_LINKAGE , 
SET_TYPE_MEMBER  and  RECORDSET  tables. 

4.  For  a  CODASYL  DBMS  multiple  members  are  allowed. 
Verify  that  the  owner  record  and  member  record(s) 
have  been  previously  defined.  A  required/ optional 
entry  must  be  specified  for  the  member  record 
types.  The  set  information  is  then  inserted  into 
the  SET  TYPE  MEMBER  and  RECORD  SET  tables. 
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5.  Processing  halts  if  any  of  the  verification  checks 
fail . 
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CDM  TABLES  ACCESSED  -  DEFINE  SET 


(S-8QL.  ■-■DHL) 


TABLE  NAME 


SELECT 


MOD I  FT 


u 


DATA  BASE 


■(VERDBAS) 


DATA  FIELD 


>( VERDFLD) 


DF  SET  LINKAGE 


S( INSD6L ) 


RECORD  SET 


N(VERRSET) 


somrskt) 


RECORD  TYPE 


N(VERRT) 


SET  TYPE  MEMBER 


S(IMSTM) 
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*  Int  flit  ud  if  Um  flic  cmUIm  date,  only 
pr«-«Klitiaf  dMoriptloi  lest  of  IIm  proper  type  is 
dole  tod  prior  to  Um  laser  t  loo  of  Um  see  text.  If 
Um  file  ooataias  no  date,  the  description  text  is 
not  deleted  and  aa  error  Message  is  generated.  If 
Um  text  originates  froa  the  ooanand  line,  the  old 
description  text,  if  any.  is  deleted  prior  to  the 
insertion  of  nee  text,  if  any.  Therefore,  to 
delete  old  description  text,  the  aser  nest  describe 
the  object  with  a  nail  description  on  the  ooanand 
line 

If  the  description  text  is  to  cone  froa  the  UI/UTI 
Screen  Mi  tor.  pre-existing  description  text  if 
any.  is  extracted  froa  the  database  and  written  to 
a  file 

The  U1/0TI  Screen  Mi  tor  is  called  to  edit  the 
file  If  changes  are  aade.  the  old  description  text 
is  replaced  by  the  text  oatpat  froa  the  editor.  If 

no  editing  changes  were  aade.  the  database  is  not 
Modified 
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COM  TABLES  ACCESSED  -  DESCRIBE 


TABLE  BABE _ 

ATTRI BUTECLASS 

ATTRIBUTEWAME 

DATABASE 

DATAFIELD 

DATA  ITEM 

DESCTEXT 

DOMAIN  CLASS 
EWTITYCLASS 
ENTITYNAME 
KEYWORD 
RECORD  SET 
RECORD  TYPE 
RELATIOMCLASS 
SEC 

USER  DEF  DATA  TYPE 


SELECT  MODIFY 

NCVERATT) 

N(VERATT) 

M(VERDB) 

M( VERDFLD) 

N( VERDI) 
N(OUTDESC) 

N(VERDOM) 

M(VERENT) 

N(VERENT) 

N(VERKW) 

N( VERRSET) 
N(VERRT) 

N(VERRC) 

M( VERVIEW) 

N( VERUDTN) 


(S-SQL, 

INSERT 


S  C  RDDESC , 
FILEINS) 
S( RDDESC , 
STRINS) 


N-NDML) 

DELETE 


S(DELTXT) 
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3.2.8.27  DROP  ALIAS  -  Deletes  an  alias  established  for  an 
attribute  or  entity  naae. 

A.  Function: 

Drop  Alias  perforas  the  following  functions: 

1.  verifies  whether  the  alias  is  for  an  attribute  or 
entity; 

2.  verifies  that  the  alias  exists  for  the  attribute  or 
entity  for  a  specified  aodel ; 

3.  deletes  the  Alias  for  the  attribute  or  entity. 

B.  CPM  Requireaents : 

Drop  Alias  requires  the  presence  of  an  Alias  for  the 

attribute  or  entity. 

C.  Processing: 

1.  The  DROP  ALIAS  process  will  deteraine  whether  the 
alias  is  of  an  attribute  or  entity  and  verify  if 
the  attribute  or  entity  exists  for  the  specified 
aodel . 

2.  The  process  will  then  verify  the  Alias  naae  and 
delete  the  alias  for  the  attribute/entity  froa  the 
CDM  Entity  or  Attribute  naae  table. 
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CDM  TABLES  ACCESSED  -  DROP  ALIAS 
TABLE  NAME _  SELECT  MODIFY 


ATTRI BDTECLASS 
ATTRIBUTENAME 

ENTITY_CLASS 
ENTITY  NAME 


N(VERATT) 

N(VERATT) 

N(GETACAL) 

N( VERENT) 

N(VERENT) 

H(GETECAL) 


(S-SQL.  N-NDML) 
INSERT  DELETE 


S(DELACAL) 

S(DELECAL) 
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5.2.8.28  DROP  ATTRIBUTE  -  Drop  &  Conceptual  Attribute 

A.  Function: 

Drop  Attribute  deletes  one  or  more  user  specified 

attributes  from  the  CDM. 

B.  CDM  Requirements: 

The  attribute(s)  to  be  dropped  must  exist  in  the 

current  model . 

C.  Processing: 

1.  DRPATT .  after  verifying  that  the  attribute  exists, 
determines  whether  the  attribute  to  be  dropped  is 
owned.  If  so.  the  attribute  is  deleted  from  the 
OVNEDATTRI BUTE  and  ATTRI BUTEUSECL  tables. 

2.  If  the  attribute  to  be  dropped  has  been  inherited, 
all  instances  of  inheritance  are  deleted.  The 
tables  affected  are  INHERITED  ATTUSE, 

ATTRI BUTEUSECL .  BTCLASSMEHBER  and  DESCTEXT . 

The  ORACLE  tree  search  feature  is  used  to  identify 
inheritance  at  all  lower  levels. 

3.  After  all  owned  or  inherited  Instances  of  the 
attribute  are  deleted,  the  attribute  is  deleted 
from  ATTRIBUTECLASS .  ATTRI BUTEH AM E .  ACKETVORD 
and  DESC_TEXT . 

4.  If  the  attribute  deleted  was  a  by  class  member,  and 
if  it  was  the  only  member  of  a  particular  by  class 
the  corresponding  entries  in  the  BYCLASS,  complete 
relation  and  DESC  TEXT  tables  are  deleted. 
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CDH  TABLES  ACCESSED  -  DRPATT  (S-SQL,  N-HDML) 

TABLE  NAME _  SELECT  MODIFY _ INSERT  DELETE 


ACKEYWORD 

ATTRI BUTECLASS 

N(veratt) 

ATTRIBUTENAME 

N(veratl) 

ATTRI BUTEOSECL 

N(deloac) 

COMPLETE  RELATION 

DESC_TEXT 

ENTITTCLASS 

S(delatko) 

KEYCLASS 

S(delatkc) 

KEY  CLA  SSMEMBER 

S(delatro) 

INHERITEDATTOSE 

S(delBlgk) 

OWNED  ATTRIBUTE 

S(delackw) 

S(delac) 

S(delacn») 

S(delaucl ) 

S(dekmpr) 

S(deltext) 

S(delkc) 

S(delkcmt) 

S(deliauc) 

S(delowac) 
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|  3.2.8.29 
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I 

A. 


i 


B. 


C. 


DROP  DATABASE  -  Delete  a  database  fro*  the  Common  Data 
Model . 

Function: 


Drop  Database  deletes  all  references  to  the  database 
from  the  Common  Data  Model . 

CDM  Requirements: 

1.  The  database  or  IMS  PCB  must  exist  in  the  Common 
Data  Model . 

2.  The  Common  Data  Model  database  cannot  be  dropped. 
Processing: 

After  verifying  that  the  database  or  IMS  PCB  exists, 
all  references  to  the  database  or  PCB  are  deleted  from 
the  Common  Data  Model.  If  any  of  the  data  fields  for 
the  database  or  PCB  map  to  the  INTEGRATEDMODEL ,  their 
mapping  will  be  deleted.  If  the  mapping  was  primary, 
all  secondary  mappings,  even  to  other  databases,  are 
deleted. 
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CPU  TABLES  ACCESSED  -  DROP  DATABASE 


(S-SQL,  N-NDML) 


TABLE  NAME _ SELECT 

AUC_ST_MAPP IN 

DATA  BASE  N(VERDBAS) 

DATA  BASEAREA 

DATA  FIELD 

DB_ ARE A_AS  S IGNMENT 

DF_SET_L I NKAGE 

IMS  SEGMENT_SI ZE 

PRO JECT_DATA_F I ELD  N(PDFDB) 

PCB  PSB 

RC_BASED  REC  SET 

RECORD_KEY 

RECORD  KEYMEMBER 

RECORDSET  N ( VERSTNO ) 

RECORD_TYPE 

SCHEMANAME 

SEGMENT  DATA  FIELD 


MODIFY  INSERT  DELETE 

S(DELASMl) 

S(DELDBSl) 

S(DELDBAl) 

S(DELDFLl) 

S(DELDAAl) 

S(DELDSLl) 

S( DELI SSI) 

S(DELPDFT) 

S(DELIPDF) 

S(DELPCB) 

S(DELRBRl) 

S ( DELRKY 1 ) 

S(DELRKMl) 

S(DELRST2) 

S(DELRTYl) 

S ( DELSN 1 ) 

S(DELSDFl) 

SCDELSTM1 ) 


SET  TYPE  MEMBER 
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3.2.8.30  DROP  DOMAIN  -  Drop  a  Domain  definition  from  the  CDM. 

A .  Function : 


DROP  DOMAIN  allows  the  NDDL  User  to  drop  the 
definitions  of  one  or  more  domains  from  the  CDM. 

B.  CDM  Retruirements : 

The  domains  to  be  dropped  must  currently  exist, 
independent  of  model,  and  no  attributes,  data  items  or 
data  fields  must  be  associated  with  the  data  types 
defined  for  the  domain. 

C.  Processing: 

1.  For  each  domain  name  specified  by  the  user,  the 

following  is  done: 

1.1  The  domain  name  is  verified,  retrieving  its 
domain  number. 

1.2  Any  attribute  class  associated  with  the  domain 
are  searched.  This  search  is  possible  because 
the  standard  data  type  of  the  domain  is  the 
only  data  type  associated  with  attributes. 

1.3  For  each  data  type  associated  with  the  domain: 

1.3.1  Usage  of  the  data  type  by  any  internal 
schema  data  fields  is  determined  and 
displaced  to  the  user. 

1.3.2  Usage  of  the  data  type  by  any  external 
schema  data  items  is  determined  and 
displaced  to  the  user. 

1.4  If  the  count  of  usages  of  any  data  types  of 
this  domain  is  not  zero,  the  user  is  given  a 
message  and  the  domain  will  not  be  deleted. 

1.5  If  the  domain  can  be  deleted,  the  following 
steps  are  executed: 

1.5.1  All  data  types  can  be  deleted,  reassigning 
their  unique  numbers  to  the  reusable  list. 
The  data  type  descriptions  are  also  deleted. 
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.5.2  The  DOMAINCLASS  entry  itself  can  be 

deleted,  along  with  any  associated  text 
descriptions.  Its  unique  number  is  added  to 
the  pool  of  re-usable  numbers. 
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CDM  TABLES  ACCESSED 

-  DROP  DOMAIN 

(S-SQL,  N-NDML) 

TABLE  NAME 

SELECT  MODIFY 

INSERT  DELETE 

ATTRIBOTECLASS 

N( VERACDT) 

DATA_ITEM 

N(VERDIDT) 

DESC_TEXT 

S(DELTEXT) 

DOMAIN  CLASS 

N(VERDOM) 

S(DELDOM) 

PRO  JECTDAT  A_F I ELD 

N( VERDFDT) 

USERDEFDATATYPE 

N(DOMUSAG) 

N(DELDTNO) 

S(DELDTD) 
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3.2.8.31  DROP  ENTITY  -  Drop  a  conceptual  entity 

A.  Function: 


Drop  Entity  performs  the  following  functions: 

1.  delete  one  or  more  user  specified  entities  from  the 
CDM. 

2.  deletes  the  primary  name  of  the  entity  and  all 
associated  aliases,  keywords  and  description  text. 

3.  deletes  all  associated  owned  attributes,  attribute 
use  classes  and  inherited  attributes. 

4.  deletes  all  associated  key  classes  and  key  class 
members . 

5.  deletes  all  relation  classes  associated  with  the 
entity  and  its  keywords. 

B.  CDM  Requirements: 

Each  entity  to  be  dropped  must  exist  in  the  current 

model . 

C.  Processing : 

1.  The  Drop  Entity  process  verifies  that  the  entity  to 
be  dropped  exists  in  the  current  model.  If  it  does 
not  exist  an  error  is  issued  and  processing  is 
terminated. 

2.  The  process  next  determines  all  owned  attributes 
and  attribute  use  classes  for  the  entity  and  these 
are  dropped.  Further,  its  key  classes  and 
attributes  inherited  via  the  migrated  keys  and  key 
class  members  are  also  dropped.  If  the  deletion  of 
the  entity  resulted  in  any  empty  key  classes  for 
the  model,  these  are  then  deleted. 

3.  Next  all  relations  where  the  entity  is  independent 
and  dependent  are  deleted  as  is  its  associated 
keywords . 


Finally,  the  primary  name  of  the  entity  and  all  of 
its  aliases  keywords  and  description  text  are 
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deleted  fro*  the  Model 


ATTRIBUTE  OSS  CL 

■(  DBLOAC  ) 

■(PRDAOC) 

S( DCLAUCL ) 

COMPLETE  RELATION 

S( DBLCMPR ) 

DC  SC  TEXT 

S ( OCLTEXT ) 

bc  ebtvord 

S( DCLBCEW ) 

bstitt  class 

M( VEREST ) 

S(DCUfTEC) 

S(OCLBC) 

BUT ITT  SAMS 

■(VEREST) 

s(  dclrcrm  > 

INHERITED  ATT  CL 

S( DELHI OR ) 

S( DCLIAOC ) 

BBT  CLASS 

S( OBLNTEC ) 

S<  DELBC ) 

BBT  CLASS  NEHSSR 

S( DCLSTEC ) 

S( DCLBCMT ) 

OWED  ATTRIBUTE 

R(rSDOAC) 

S(OCLOWAC) 

SC  BET WORD 

S(  DCLRCXV  ) 

RELATION  CLASS 

■  (DRPRCE) 

S(  DELRC  ) 

3  105 


DC  620141100 
1  Bov— hr  1965 


4  Delete  any  textual  descriptions  of  the  data  field 

5  Verify  the  existence  of  any  record  sets  associated 
with  data  field  throufh  the  DATA  FIILD  SET  LINKAGE 
entity  Por  each  one  found 

5  1  Delete  the  set  f roe  DF  SET  LINKAGE  entity 
occurrence 

5  2  Delete  the  SET  TYPE  MEMBER  entity  occurrences 
for  the  record  set 

3  3  Delete  the  RECORD  SET  entity  occurrence  for 
this  set 

3  4  Delete  the  ADC  SET  HAPPING  entity  occurrences 
for  this  set 


•>  Delete  the  RC  BASED  REC  SET  entity  occurrences 
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for  this  set. 

5.6  Delete  the  SEGMEHTDATAFIELD  entity 
occurrences  for  this  set. 

6.  Delete  the  DATA_FIELD  entity  itself. 

7.  Delete  the  RECORDKEYMEMBER  entity  occurrences  for 
this  data  field. 

8.  Delete  the  RECORDKEY  entity  occurrences  for  this 
data  field. 

9.  Delete  the  PROJECTDATAF 1 ELD  entity  occurrences 
for  this  data  field.  If  the  mappings  was  primary, 
delete  all  other  data  field  mappings  for  the  same 
attribute  use  class. 
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CPH  TABLES  ACCESSED  -  DROP  FIELD 

TABLE  MAKE _ SELECT  MODIFY 

AOCSETMAPPIHG 

DATABASE  N(VERDBAS) 

DATAFIELD  N( VERDFLD) 

DATAFIELD 
DESC_TEXT 

DF_  S  ET_L I NKAGE  N( VERDSL3) 

PROJECT  DATA  FIELD  M(PDFDF) 


RCBASEDRECSET 

RECORDKEY 

RECORDKEYMEMBER 

RECORDSET 

SEGMENTDATAF I ELD 

SET  TYPE  MEMBER 


(S-SQL,  M«HDML) 
INSERT  DELETE 

SCDELASM2) 

S ( DELDFL3 ) 

S(DELTEXT) 

S ( DELDSL3 ) 

S(DELPDFT) 
S( DELI PDF) 
SCDELRBR3) 
SCDELRKY2) 

SCDELRKM3) 

SCDELRST3) 

SCDELSDF3) 

SCDELSTM3) 
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3.2.8.33  DROP  KEYWORD  -  Delete  an  object  keyword. 

A.  Function: 

Drop  Keyword  performs  the  following  function: 

1.  delete  the  naaed  keyword  and  associations  with  any 
attribute,  entity  and/or  relation  class. 

B.  CPU  Requirenents : 

The  keyword  to  be  dropped  nust  exist  in  the  CDM . 

C.  Processing: 

1.  Drop  keyword  verifies  the  existence  of  the  keyword. 
The  keyword  is  deleted  froa  the  ACKETNORD. 

ECKETV ORD .  RC_ KEYWORD .  and  froa  the  KETVORD 
tables . 

2.  Processing  halts  if  any  of  the  verification  checks 
fail . 
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CPU  TABLES  ACCESSED  -  PROP  KEYWORD  ( S-SQL ,  R-RDML) 


TABLE  MAKE 
AC  KEYWORD 
DESCTEXT 
EC  KEYWORD 
KEYWORD 
RC  KEYWORD 


SELECT  MODIFY 


H(VERKW) 


IRSERT  DELETE 

S(DELKWAC) 

S(DELTEXT) 

S(DELKWEC) 

S(DELKW) 

S(DELKWRC) 
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3.2.8.34  DROP  MAP  -  Delete  a  CS-IS  Mapping 

A.  Function: 

Drop  Map  performs  the  following  functions: 

1.  delete  all  mappings  from  a  particular  attribute  use 
class  (AUC)  or  from  a  particular  RELATIONCLASS . 

B.  CDM  Requirements: 

The  map  to  be  dropped  must  exist  on  the  CDM. 

C.  Processing: 

1.  After  validating  that  the  map  exists,  the 

appropriate  PRO JECTDATAF I ELD ,  AOC_ST_MAPPING  or 
RCBASEDRECSET  entity  is  deleted. 
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CPU  TABLES  ACCESSED  -  DROP  MAP  (S-SQL,  N-NDML) 


TABLE  MANE 

SELECT  MODIFY 

INSERT 

DELETE 

ATTRIBUTEUSECL 

M(VERAUC) 

AUC_ST_MAPP I MG 

M(VERASM) 

S(DELASM) 

ENTITYCLASS 

H(VERENT) 

ENTITY  MANE 

M(VEREMT) 

PRO JECTDATAF I ELD 

N( PDFSRCH) 

S(DELPDFT) 

RCBASEDREC  SET 

N(VERRCST) 

S(DELRCST) 

RELATIONCLASS 

M(VERRC) 
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3.2.8.35  DROP  MODEL  -  Delete  a  model  from  the  CDM. 

A.  Function: 

Drop  Model  performs  the  following  functions: 

1.  drop  all  entities  associated  with  the  model. 

2.  drop  all  attributes,  attribute  use  classes,  and 
inherited  attributes  associated  with  the  model. 

3.  drop  all  key  classes,  and  key  class  members 
associated  with  the  model. 

4.  drop  all  relations  associated  with  the  model. 

5.  drop  all  descriptions,  aliases  and  keywords  for  the 
entities,  attributes  and  relations  associated  with 
the  model . 

B.  CDM  Requirements: 

The  model  to  be  dropped  must  exist  in  the  CDM. 

C.  Processing: 

1.  Drop  Model  verifies  that  the  model  to  be  dropped 
exists.  The  INTEGRATED_MODEL  cannot  be  dropped. 

2.  For  each  entity  found  in  the  model,  its  owned 
attributes,  keywords,  descriptions  and  the  entity 
itself  is  dropped.  Further,  its  key  classes  and 
attributes  inherited  via  the  migrated  keys  and  key 
class  members  are  also  dropped.  Relations  where 
the  entity  is  both  dependent  and  independent  are 
deleted,  so  also  its  associated  keywords  and 
descriptions . 

3.  Finally,  for  each  attribute  in  the  model,  the 
attribute  keywords,  descriptions  and  the  attribute 
itself  is  dropped. 

4.  Processing  halts  if  any  of  the  verification  checks 
fail . 
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CDM  TABLES  ACCESSED  -  DROP  MODEL  (S-SQL.  N«=NDML) 


TABLE  NAME 

SELECT  MODIFY 

INSERT 

DELETE 

ACJCEYWORD 

S(DELACKW) 

ATTR I BUTECLA S S 

N(FNDACM) 

S(DELAC) 

ATTRIBUTE  NAME 

N  C  SELACNM ) 

S ( DELACNM ) 

ATTRIBUTE  USE  CL 

N ( DLMDAUC ) 

S ( DELAUCL ) 

COMPLETE  RELATION 

S ( DELCMPR ) 

DESCTEXT 

S(DELTEXT) 

EC  KEYWORD 

S(DELECKW) 

ENTITYCLASS 

N(FNDECM) 

S(DELEC) 

ENT I TY_NAME 

N(SELECNM) 

S(DELECNM) 

I NHER I TED_ATT_USE 

SC DELI AUK) 

KEYCLASS 

N(DELMDKC) 

S(DELKC) 

KE Y_CLAS  SMEMBER 

S(DELKCMT) 

MODEL  CLASS 

N(VERMOD) 

S(DELMOD) 

OWNED_ ATTR I BUTE 

S ( DELOACE ) 

RC_KEYWORD 

S(DELRCKW) 

RELATION_CLASS 

N(DELMDRC) 

S(DELRC) 
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3.2. 8. 36  DROP  RECORD  -  Delete  the  Record  Type /Table /Segment  from 
the  Internal  Schema  database. 

A.  Function : 

Drop  Record  performs  the  following  functions: 

1.  Deletes  all  references  to  the  Record 
Type/Table/ Segment  from  the  internal  schema 
portion  of  the  CDM . 

2.  Deletes  all  associated  Data  Fields,  Segment 
data  fields,  database  Areas,  project  data 
fields,  record  keys,  record  key  members,  data 
field  linkage,  record  sets  and  record  set 
members.  Additionally,  all  text  descriptions 
for  the  record  type/segment  data  field,  and 
record  sets  are  deleted. 

B.  CDM  Requirements : 

The  Record/Table/ Segment  to  be  dropped  and  the 
database  the  Record  Type  must  exist  in  the  CDM 
database . 

Processing: 

1.  Drop  Record  verifies  the  existence  of  the 
database/ PCB  specified  and  the  record 
type/ table/ segment  specified.  If  the  database 
or  record  type  does  not  exist,  processing  stops 
and  an  error  message  is  issued. 

2.  The  Record/Table/ Segment  is  deleted  from  the 
CDM;  all  associated  textual  description  about 
the  record  are  deleted;  and  the  record's  object 
number  is  added  to  the  reusable  number  table. 

3.  The  process  then  queries  for  and  deletes  all 
database  area  assignments  associated  with  the 
record/ table/ segment .  All  data  fields  that 
belong  to  the  record  are  deleted  along  with 
their  associated  textual  description.  The 
process  then  deletes  all  reference  to  the 
record/ table/ segment  in  the  Project  data  field. 
Record  key  and  Record  key  member  tables. 
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4.  Specialized  processing  for  IHS  databases 
deletes  the  record  fron  IMS  SEGMEHTSIZE  and 
the  Segment  Data  Field  CDM  tables.  For  TOTAL 
databases  the  DFSETLIKXAGE  table  has  all 
reference  to  the  record  removed. 

5.  Final  processing  is  to  delete  all  RecordSets 
or  Record  Set  members  that  contain  the 
record/table/segment  to  be  dropped.  The  Record 
Set  processing  will  delete  all  reference  to  the 
Record/ table/ segment  where  it  is  an  owner 
record  or  member  record  and  any  set  that 
becomes  member less  when  the  dropped  record  was 
the  set  member. 
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CDM  TABLES  ACCESSED 

-  DROP  RECORD 

( S=SQL ,  N=NDML) 

TABLE  NAME 

SELECT  MODIFY 

INSERT  DELETE 

AUC  ST  MAPPING 

SCDELASM2) 

DB_ ARE A_AS  SIGNMENT 

S ( DELDAA2 ) 

DATA  BASE 

N(VERDBAS) 

DATA  FIELD 

S( DELDFL2 ) 

S(PRPDF) 

DFSET  LINKAGE 

S ( DELDSL2 ) 

DESCTEXT 

S ( DELTEXT ) 

I MS  SEGMENTS I ZE 

S(DEL1SS2 ) 

PRO JECT_DATA_FI ELD 

N(PDFREC) 

S ( DELPDFT ) 
S( DELI PDF) 

RC  BASED  REC_SET 

S ( DELRBR2 ) 

RECORD  KEY 

S(DELRKY2) 

RECORD  KEY  MEMBER 

S ( DELRKM2 ) 

RECORDSET 

N( SELRSET) 

S ( DELRST2 ) 

RECORDTYPE 

N(VERRT) 

S(DELRTY2) 

SEGMENTDAT A -FI ELD 

S(DELSDF2) 

SET  TYPE  MEMBER 

N(SELSTM) 
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3.2.8.37  DROP  RELATIOM  -  Deletes  the  relation  class  and  all 
references  to  the  relation  class  froa  the  CDM 
database . 

A.  Function: 


The  Drop  Relation  process  perfo ras  the  following 

functions  for  one  or  aore  relations: 

1.  verifies  that  the  relation  class  exists; 

2.  verifies  that  the  independent  and  dependent 
entities  exist; 

3.  deletes  the  relation  class  froa  the  CDM; 

4.  deletes  the  coaplete  relation; 

5.  deletes  all  keys  that  have  Bigrated  froa  the 
relation  class; 

6.  deletes  all  keywords  associated  with  the  relation; 

7.  deletes  all  textual  descriptions  associated  with 
the  relation. 

B.  CDM  Requireaents : 

The  Drop  Relation  process  requires  the  presence  of  the 

Relation  Class,  Independent  Entity,  and  Dependent 

Entity  within  the  current  aodel . 

C .  Processing : 

1.  The  Drop  Relation  process  verifies  that  the 
independent  entity,  dependent  entity,  and  the 
relation  exist  in  the  CDM.  If  any  of  these  do  not 
exist,  an  error  is  issued  and  processing 
terminates . 

2.  The  process  verifies  whether  the  relation  is 
complete  and  if  so  returns  the  key  class  which 
allow  the  process  to  determine  the  migration  of  the 
associated  items. 

3.  Utilizing  the  key  class  the  process  deletes  all 
migrating  key  class  member  based  on  the  relation 


TABLE  BABE  _ 


ATTBIBOTE  DIB  a 
COMPLETE  BSLATIOB 

Kirrirr  class 

ENTITY  SANE 
I SUES I TED  ATT  OSE 
KET  CLASS  HESSES 
SC  KETVOSD 

relation  class 


S( VESEWT) 

S( DCLMIGBC ) 


S(VKSBC) 


g(DBLCPSC) 


S(DKLIAOC) 
S(  DKLEOfT ) 


S(DKLSC) 


3  120 


DS  620141100 
1  November  1985 


3.2.8.38  CHOP  SET  -  Drop  a  Record  Set/from  the  Internal  Schema 

A.  Function: 


Drop  Set  allows  the  RDDL  user  to  drop  the  set  specified 
from  the  internal  schema  portion  of  the  CDM. 

B .  CPU  Requirements: 

The  set  to  be  dropped  must  have  been  already  defined  to 
the  CDM 

C .  Process 

1.  The  user  entered  database  name  is  used  to  determine 
if  the  database  exists  in  the  CDM  at  this  point. 

The  set  name  is  used  along  with  the  database  number 
to  determine  if  the  set  actually  exists.  If  so. 
all  entries  for  this  set  are  deleted  from  the 
following  tables: 

1.1  RC_BASED_REC_SET ,  CS  to  IS  relation  class  to 
set  mappings. 

1.2  AUC  ST  MAPPING,  CS  TO  IS  attribute  to  set 
mappings 

1.3  SET  TYPE  MEMBER,  all  member  record  types  for 
the  set . 

1.4  RECORD  SET,  the  record  set  occurrence  itself. 

15  For  TOTAL  DBMS  only,  the  DF  SET  LINKAGE 

occurrence  used  to  indicate  the  presence  of. 
foreign  control  keys  needed  for  TOTAL  link 
path  traversal . 

2  The  unique  set  number  is  then  added  to  the  list  of 
re-usable  set  numbers  (object  numbers)  maintained 
on  the  CDM . 


3-121 


DS  620141100 
1  November  1985 


CDH  TABLES  ACCESSED  -  DROP  SET 


S(S«SQL,N-NDHL) 


TABLE  NAME 


SELECT  MODI FT 


INSERT 


DELETE 


AUCST-MAPPING 
DATA  BASE 
DFSET  LINKAGE 
RC_BASED_REC_SET 
RECORD  SET 
SET  TYPE  MEMBER 


SCDELASM2) 


■C VERDBAS) 


N( VERRSET) 


S ( DELDSL2 ) 
S ( DELRDR2 ) 
S ( DELRST2 ) 
SCDELSTM2) 
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3.2.8.39  DROP  VIEW  -  Deletes  the  view/ surrogate  entity  class 
( SEC)  and  all  data  itees,  project  data  itens.  itens 
and  related  textual  descriptions  fron  the  COM 
database . 

A .  Function: 

The  Drop  View  process  performs  the  following  functions: 

1.  verifies  the  existence  of  the  view; 

2.  deletes  project  data  itens  associated  with  the 
view ; 

3.  deletes  the  views  8EC  RC  OOHPORERT  entries  based  on 
the  VIEW /SEC  to  relation  class  napping; 

4.  deletes  all  data  itens  and  data  iten  textual 
descriptions ; 

3.  deletes  the  VIEW/ SEC. 

B.  CDH  Requirenents : 

The  Drop  View  process  requires  that  the  view  exist  in 

the  external  schena  portion  of  the  CDM  database 

C .  Process i  ng_: 

1 .  For  each  view  entered  the  Drop  View  process 
verifies  that  the  view  to  be  dropped  exists  in  the 
CDM  database.  If  the  view  does  not  exist,  an  error 
nessage  is  issued  and  processing  terninates 

2.  The  process  will  delete  all  project  data  itens  and 
the  VIEV/SEC  to  relation  class  nappings  that  are 
based  on  the  view.  The  process  selects  all  data 
itens  belonging  to  the  view,  deletes  the  textual 
descriptions  and  then  delete  all  data  itens 


3. 


The  process  deletes  the  VIEW/SEC  and  all  associated 
textual  descriptions 


DS  620141100 
1  loveaber  1065 

CPU  TABUS  AOCHIP  -  POOF  VIEW  ( S-SQL  .M-MDML) 

TABLE  MAKE _ 1ELECT  MODI  FT  IWgT  DELETE 


DATA  ITEM  KDBPD1V) 

PROJECT  DATAITEM 
SEC  ■( VEBVIEV) 

SEC  RC  OOMPOBEBT 


S(DELDIV) 
S( DELPDI ) 
S( DELS EC) 
S(DELSECR) 
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5.2.8.40 

A. 

B. 


HALT  -  Terminate  the  current  NDDL  session 
Funct 1 on : 

Halt  terminates  the  current  NDDL  session. 

Processing : 

If  any  errors  were  detected  during  the  NDDL  session,  am 
ORACLE  rollhack  is  performed.  If  no  errors  were 
detected,  an  ORACLE  commit  is  performed. 
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CPU  TABLES  ACCESSED  -  HALT 
NONE 
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3.2.8.41  MERGE  MODEL  -  Merge  two  conceptual  models. 

A.  Function: 


Merge  Model  performs  the  following  functions: 

1.  merge  two  models  into  the  first-named  model  or  into 
a  newly  created  third  model. 

2.  generate  NDDL  commands  on  a  file  to  populate  either 
the  first  model  or  the  third  model  with  the 
attributes,  entities,  relations,  key  classes,  key 
class  members,  aliases,  keywords  and  descriptions 
from  model  one  and  model  two. 

B.  CDM  Requ i remen t  s : 

1.  Model  one  must  exist  in  the  CDM. 

2.  Model  two  must  exist  in  the  CDM. 

3.  If  model  three  is  specified,  it  must  not  exist  in 
the  CDM. 

C.  Processing: 

1.  Verify  the  existence  of  model  one  and  model  two. 
Note  that  processing  halts  if  any  verification 
checks  fail. 

1.1  If  model  three  was  not  specified,  default 
model  three  to  model  one;  otherwise,  verify 
that  model  three  does  not  exist. 

1.2  If  model  three  does  not  exist,  copy  everything 
from  model  one  to  model  three  using  the  COPY 
MODEL  routines. 

2.  Build  the  key  class  list  for  all  the  entities  in 
model  two. 

3.  Next,  add  all  the  model  two  top  node  entities  to 
model  three.  If  the  model  two  entity  does  not 
exist  in  model  one,  then  COPY  ENTITY  routines  are 
used  to  add  the  entity  to  model  three.  Otherwise, 
COMBINE  ENTITY  routines  are  used  to  combine  the 
model  two  entity  with  the  model  one  entity  with  the 
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result  added  to  model  three. 

4.  Next,  add  all  the  model  two  dependent  entities, 

attributes,  relations,  keys,  and  key  class  members, 
aliases  keywords,  and  descriptions  to  model  three, 
level  by  level.  If  the  model  two  entity,  attribute 
and/or  relation  does  not  exist  in  model  one,  then 
COPY  ENTITY  routines  are  used  to  add  the 
information  to  model  three.  Otherwise,  COMBINE 
ENTITY  routines  are  used  to  combine  the  model  two 
information  with  model  one  with  the  result  added  to 
model  three. 
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CDM  TABLES  ACCESSED  -  MERGE  MODEL  (S-SQL.N-NDML) 

TABLE  NAME _ SELECT _ MODIFY _ INSERT _ DELETE 

ENTITYCLASS  S(MRGNODE) 

S ( MRGM0D2 ) 

ENTITYNAME  N( SELECNM ) 

MODEL  CLAS  S  S ( MRGNODE ) 

SCMRGM0D2) 

RELATIONCLASS  S  C  MRGNODE ) 

SCMRGM0D2) 
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3.2.8.42  RENAME  -  Rename  object  names  for  a  particular  object 

type. 

A.  Function: 

Rename  performs  the  following  functions: 

1 .  change  an  old  object  name  to  a  new  object  name 
for  object  types  -  entity,  attribute,  keyword, 
model,  domain,  view  and  relation. 

B.  COM  Recru  i  remen t  s : 

The  object  names  to  be  renamed  must  exist  in  the 

CDM . 

C .  Processing: 

1.  Rename  verifies  the  existence  of  the  old 
object  name.  To  rename  a  relation  class,  the 
independent  entity,  relation  name  and 
dependent  entities  existence  is  verified. 

2.  Next,  it  verifies  that  the  new  object  name(s) 
does  not  previously  exist  for  the  particular 
object  type. 

3.  Finally,  the  old  object  name  is  updated  in  the 
CDM  with  the  new  object  name. 

4.  Processing  halts  if  any  of  the  verification 
checks  fail. 
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CDM  TABLES  ACCESSED 

-  RENAME 

( S=SQL ,  N-NDML) 

TABLE  NAME 

SELECT 

MODIFY 

INSERT  DELETE 

ATTRIBUTECLASS 
ATTRIBUTENAME 
DOMAINCLASS 
ENTITY  CLASS 
ENTITY  NAME 
KEYWORD 
MODEL  CLASS 
MODELNAME 
RELATION  CLASS 
SEC 


N(VERATT) 

N(VERATT)  S(OPDACNM) 
N(VERDOM)  S(UPDTDOM) 
N(VERENT) 

N(VERENT)  S(UPDECNM) 
N(VERKW)  S(UPDTKW) 
N(VERMOD) 

S(UPDRCNM) 
N(VERRC)  S ( UPDRCNM ) 
N(VERVIEW)  S(UPDVIEW) 
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3.3  Performance  Requirements 

3.3.1  Programming  Methods 

Structured  Design,  structured  code  walkthroughs  and 
structured  programming  will  be  used  wherever  possible. 

Debugging  through  use  of  a  symbolic  debugger  will  also  be  used 

3.3.2  Program  Organisation 

NDDL  processor  will  be  organised  as  a  single  executable 
image.  It  will  use  the  forms  processor  directly.  The  DBMS 
access  will  be  done  through  ORACLE  services  communicating  with 
the  actual  DBMS  processes.  The  NDML  will  be  used  for  database 
access  and  it  is  designed  to  communicate  via  the  IISS  NTH  to  the 
actual  request  processors.  The  NDDL  processor  will  consist  of  a 
main  routine,  an  initialisation  routine  to  establish  all  the 
environments,  a  command  initialisation  routine  to  dear  the 
parser  command  processor  interface  data  structure,  a  command 
processor  entry  point  for  each  command  and  a  termination 
routine. 

3.3.3  Modification  Consideration 


It  would  be  useful  to  investigate  the  creation  of  a 
seperate  process  for  each  command  processor.  Each  would  have 
its  own  processor.  (71  function  screen  or  menu  interface  would 
allow  command  selection.  A  forms  driven,  rather  than  syntax 
driven  approach  could  also  be  considered.  Continued  evolution 
of  NDML  facilities  should  be  monitored,  such  as  generation  of 
"in-line”  code,  replacement  of  ORACLE  with  NDML  update 
facilities  and  removed  of  many  calls  to  routines  that  provide 
integrity  tests,  currently  coded  as  seperate  NDML  verification 
routines,  since  NDML  would  generate  these.  Security 
considerations  for  a  group  of  different  user  types  must  also  be 
considered.  Facilities  for  displaying  the  CDM  contents  must 
also  be  considered,  specifically  generating  the  NDDL  that 
originally  populated  the  object.  The  NDDL  processor  must 
continually  be  updated  as  new  features  and  data  tables  are  added 
to  the  CDM. 

3.3.4  Special  Features 

3.3.5  Expand ibi 1 ity 

The  NDDL  can  be  expanded  very  simply  in  the  area  of  new 
commands.  Parsing  directives  must  be  written  and  new  command 
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processors  dcsifssd  sad  isplssntsd  without  affsctisf  the 
co— sad  processing  shell  or  existing  cosesadt 

3  4  hnean  Per forasace 

The  IDOL  processor  should  allow  the  CDMA  to  reliably 
aaintam  the  nost  i epor tan i  parts  of  the  COH  and  to  effectively 
per fore  the  function  of  data  adnini strat i on 

3  3  Pet abase  dequ i regents 

3  S  1  Database  Overview 

The  COH  database  is  relational  neaaing  that  it  consists  of 
tables  that  reseable  traditional  sequential  files  The  rows  of 
the  tables  are  siailar  to  records  in  a  file  and  the  coin— is  are 
siailar  to  fields  on  the  records  Col wans  froa  different  tables 
are  soaetiaes  conbined  to  fore  'views*  tc  ease  nan l pul at  ion  of 
the  data  The  COM  database  was  derived  directly  from  the 
definitions  found  in  the  COM- 1  aodel .  deference  dunber  11 

362  delations  between  Tables  and  Views 

A  single  coaplete  view  has  been  created  for  each  table  of 
the  COM  accessed  by  BOOL 

353  Detailed  Descript i on  of  Tables  and  Views 

This  following  an  ORACLE  listing  of  the  tablet  <.  clusuni  nl 
the  CDH  Bv  using  the  table  n asset  definitions  of  each  nay  be 
found  ir  the  COM  1  node. 
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ORACLE  DATA  DICTIOMABY  00L  TABLE 


T8AMX 

CBAME 

OOLTTP 

WIDTH 

BOLLS 

AC  EETMOMD 

AC  BO 

BOMBEB 

0 

BOT  BOLL 

KB, BO 

BUMBEB 

0 

BOT  BOLL 

APPLICATION 

APPLICATION  MOO  ID 

CBAB 

10 

BOT  BOLL 

MOST  ID 

CRAB 

30 

BOT  BOLL 

ATT* I BOTE  CLASS 

AC  BO 

BOMBEB 

0 

BOT  BOLL 

DONATE  BO 

BOMBEB 

0 

HOT  BULL 

moobl  io 

BOMBEB 

0 

BOT  BOLL 

ATTB1B0TE  BANE 

AC  BANE 

CEAB 

30 

BOT  BOLL 

AC  BAMS  TYPE 

CMAB 

6 

BOT  BOLL 

AC  BO 

BOMBEB 

0 

BOT  BOLL 

ATT* I BOTE  USE  CL 

AC  BO 

BOMBEB 

0 

BOT  BOLL 

BC  BO 

BOMBEB 

0 

BOT  BOLL 

TAG  BANE 

CMAB 

30 

BOT  BOLL 

TAG  BO 

BOMBEB 

0 

BOT  BOLL 

AOC  OOBSTBAIBT 

oowtbaxbt  bo 

BOMBEB 

0 

BOLL 

STWr  ACTION 

CMAB 

SO 

BOLL 

TAG  NO 

BOMBEB 

0 

BOLL 

A DC  ST  MAPPING 

AOC  VALOC 

CMAB 

SO 

BOT  BOLL 
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ORACLE  DATA  DICTIORART:  OOL  TABLE 


TRAMS 

CRAMS 

OOLTTP 

WIDTH 

NULLS 

DB  ID 

NUMBER 

0 

NOT  NULL 

SET  ID 

CHAR 

30 

NOT  NULL 

TAG  NO 

NUMBER 

0 

NOT  NULL 

COM  VERSION 

RELEASE  NO 

NUMBER 

0 

NULL 

COMPLETE  RELATION 

EC  NO 

NUMBER 

0 

NOT  NULL 

RC  NO 

NUMBER 

0 

NOT  NULL 

COPY  LIBRARY 

LIBRARY  NAME 

CHAR 

30 

NOT  NULL 

COPY  MACRO 

LIBRARY  NAME 

CHAR 

30 

NOT  NULL 

MACRO  NAME 

CHAR 

8 

NOT  NULL 

MACRO  PURPOSE 

CHAR 

80 

NOT  NULL 

DATA  BASE 

DBMS  NAME 

CHAR 

30 

NOT  NULL 

DB  ID 

NUMBER 

0 

NOT  NULL 

DB  HAMS 

CHAR 

30 

NOT  NULL 

HOST  ID 

CHAR 

30 

NOT  NULL 

DATA  BASE  AREA 

AREA  ID 

CHAR 

30 

NOT  NULL 

DB  ID 

NUMBER 

0 

NOT  NULL 

DATA  ELEMENT 

DE  NAME 

CHAR 

30 

NULL 

HD 

NUMBER 

0 

NULL 

PIC  8ISE 

NUMBER 

0 

NULL 

PURPOSE 

CHAR 

240 

NULL 

TYPE 

CHAR 

1 

NULL 

», 

n: 

1 

1 
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ORACLE  DATA  DICTIONARY : 

COL  TABLE 

TRANE 

CNAME 

COLTYP 

WIDTH 

NULLS 

i 

t 

\ 

DATA  FIELD 

COMPONENT  OF 

NUMBER 

0 

NULL 

\ 

DATA  TYPE  NAME 

CHAR 

30 

NULL 

DB  ID 

NUMBER 

0 

NULL 

DF  ID 

CHAR 

30 

NULL 

DF  NO 

NUMBER 

0 

NULL 

v! 

OCCURS 

NUMBER 

0 

NULL 

REC  KEY  CODE 

CHAR 

1 

NULL 

'V 

REC  SEQ  NO 

NUMBER 

0 

NULL 

REDEF  DF  NO 

NUMBER 

0 

NULL 

RT  ID 

CHAR 

30 

NULL 

.V 

DATA  ITEM 

DATA  TYPE  NAME 

CHAR 

30 

NOT  NULL 

iS 

DI  ID 

CHAR 

SO 

NOT  NULL 

DI  NO 

NUMBER 

0 

NULL 

,*.1 

\l 

VIEW  NO 

NUMBER 

0 

NOT  NULL 

DATA  TYPE 

TYPE  DESC 

CHAR 

60 

NOT  NULL 

TYPE  ID 

CHAR 

1 

NOT  NULL 

DBMS 

DBMS  NAME 

CHAR 

30 

NOT  NULL 

DB  MODEL 

CHAR 

1 

NOT  NULL 

•», 

DBMS  COPY  LIBRARY 

DBMS  NAME 

CHAR 

30 

NOT  NULL 

V 

j 

LIBRARY  NAME 

CHAR 

30 

NOT  NULL 

DBMS  OR  HOST 

DBMS  NAME 

CHAR 

30 

NOT  NULL 

HOST  ID 

CHAR 

30 

NOT  NULL 

DB  AREA  ASSIGNMENT 

AREA  ID 

CHAR 

30 

NOT  NULL 

DB  ID 

NUMBER 

0 

NOT  NULL 

•;S 

RT  ID 

CHAR 

30 

NOT  NULL 

*.fc 

DB  PASSWORD 

DB  ID 

NUMBER 

0 

NOT  NULL 

DB  PASSWORD 

CHAR 

30 

NOT  NULL 

DESCRIPTION  TYPE 

DESC  TYPE 

CHAR 

30 

NOT  NULL 

t 

DESC  TEXT 

DESC  TEXT 

CHAR 

80 

NULL 

> 

.‘i 

•< 

,< 

DESC_TYPE 

CHAR 

30 

NOT  NULL 
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OBACLE  DATA  DICTIONARY :  OOL  TAILS 


THAME 

CMAMS 

OOLTYP 

WIDTH 

NULLS 

LIME  >0 

NUMBER 

0 

NOT  NULL 

OBJECT  NO 

NUMBER 

0 

NOT  NULL 

OBJECT  TYPE 

CBAR 

90 

NOT  NULL 

DF  SET 

LINKAGE 

DB  ID 

NUMBER 

0 

NOT  NULL 

DP  ID 

CHAR 

90 

NOT  NULL 

LIBXAGE  TYPE 

CBAR 

1 

NOT  NULL 

NT  ID 

CHAR 

90 

NOT  NULL 

SET  ID 

CBAR 

90 

NOT  NULL 

DOMAIN 

CLASS 

DOMAIN  NAME 

CBAR 

90 

NULL 

DOMAIN  NO 

NUMBER 

0 

NULL 

DOMAIN 

RANGE 

BEGIN  VALUE 

CBAR 

90 

NULL 

DOMAIN  NO 

NUMBER 

0 

NOT  NULL 

END  VALUE 

CBAR 

90 

NULL 

DB  030141 100 


1  lovwbtr  1085 


ORACLE  DATA  DICTIONARY:  OOL  TAILS 


THAME 

CRANE 

OOLTTP 

WIDTH 

NULLS 

DOMAIN  VALUE 

DOMAIN  BO 

HUMBER 

0 

MOT  HULL 

SPECIFIC  VALUE 

CHAR 

SO 

NULL 

ECHTUD 

DT  BO 

NUMBER 

0 

NULL 

EC  BO 

HUMBER 

0 

NULL 

UNIONVALUE 

CHAR 

SO 

HULL 

EC  00H8THAIHT 

CONSTRAINT  BO 

HUMBER 

0 

NULL 

EC  BO 

HUMBER 

0 

NULL 

8TMTACTI0N 

CHAR 

SO 

NULL 

EC  KETHOHD 

EC  BO 

HUMBER 

0 

HOT  NULL 

EV  BO 

HUMBER 

0 

HOT  NULL 

EHTITT  CLAS8 

EC  BO 

HUMBER 

0 

HOT  NULL 

MOOKL_NO 

HUMBER 

0 

NOT  HULL 

EHTITT  HAME 

EC  HAMS 

CHAR 

SO 

HOT  HULL 

EC  HAME  TYPE 

CHAR 

6 

HOT  NULL 

ECHO 

HUMBER 

0 

HOT  HULL 

GENERATED  AP 

GENERATED  NOD  ID 

CHAR 

10 

HOT  HULL 

GENERATOR_ NOD  I D 

CHAR 

10 

NOT  NULL 

GENERATED  AP  PSB 

GENERATED  HOD  ID 

CHAR 

10 

HOT  NULL 

PSB  NAME 

CHAR 

8 

NOT  NULL 
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ORACLE 

TRANE 

BOR I ZORTALPART 

HOST 

1MS_SEGMENT_SIZE 

IRHERITEDATTUSE 

KEYWORD 

KEYCLASS 

KEY  CLASS_MEMBER 
MACRO  CODE 

MODEL  CLASS 


DATA  DICTIONARY :  COL  TABLE 


CRANE 

OOLTYP 

WIDTH 

HULLS 

OORSTRAIRT  HO 

HUMBER 

0 

HULL 

DB  ID 

HUMBER 

0 

HULL 

EC  HO 

HUMBER 

0 

HULL 

RTHO 

HUMBER 

0 

HULL 

HOST  ID 

CHAR 

30 

HOT  MULL 

DB  ID 

HUMBER 

0 

NOT  HULL 

RT  ID 

CHAR 

30 

ROT  NULL 

SEGMENT  SIZE 

NUMBER 

0 

HOT  NULL 

KCM  TAG  HO 

HUMBER 

0 

HOT  HULL 

KC  HO 

NUMBER 

0 

NOT  HULL 

RC  HO 

NUMBER 

0 

NOT  NULL 

TAGHO 

NUMBER 

0 

NOT  HULL 

KEYWORD 

CHAR 

30 

HOT  HULL 

KWHO 

NUMBER 

0 

HOT  NULL 

EC  HO 

NUMBER 

0 

HOT  NULL 

KC  NAME 

CHAR 

30 

NOT  NULL 

KC_NO 

NUMBER 

0 

NOT  NULL 

KC  HO 

NUMBER 

0 

NOT  NULL 

TAG_NO 

NUMBER 

0 

NOT  NULL 

LIBRARY  NAME 

CHAR 

30 

NULL 

MACRO  CODE 

CHAR 

72 

NULL 

MACRO  LIRE  NO 

NUMBER 

0 

NULL 

MACROHAME 

CHAR 

8 

NULL 

DATE  CREATED 

DATE 

7 

NOT  NULL 

DATE  MODIFIED 

DATE 

7 

NOT  NULL 

MODEL  NAME 

CHAR 

30 

NOT  NULL 

MODEL  HO 

NUMBER 

0 

NOT  NULL 

MODEL  STATUS 

CHAR 

10 

NOT  NULL 

DS  620141100 
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ORACLE 

THAME 

MEWGAP 

MEXTNUMBER 

OWNEDATTRIBUTE 
PROJECTDATAF I ELD 

PROJECTDATAITEM 

PSB 

PSB  PCB 


DATA  DICTIONARY:  COL  TABLE 


CNAME 


CASEHO 

DB_ID 

GENERATEDBY 

GENERATED_MOD_ I D 

GENDATE 

I S_ ACT ION 

MODOLETYPE 

OSERMODID 

AC  NO 

NEXTNO 

OBJECTNAME 

AC_NO 

ECHO 

DATATYPEHAME 

DB  ID 

DF_ID 

PRIM  SECONDARY 
RTID 
TAG_NO 
DI_ID 

PRIMSECONDARY 

TAG_NO 

VIEVNO 

HOSTID 

PSB_NAME 

DB_ID 

KEYFEEDBACI  LEN 
PCBSEQNO 
PSB  NAME 


OOLTYP 

WIDTH 

MULLS 

NUMBER 

0 

NULL 

NUMBER 

0 

NULL 

CHAR 

10 

NULL 

CHAR 

10 

NULL 

DATE 

V 

NULL 

CHAR 

1 

NULL 

CHAR 

10 

NULL 

CHAR 

10 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

NUMBER 

0 

NOT 

MULL 

CHAR 

30 

NOT 

MULL 

CHAR 

1 

MOT 

NULL 

CHAR 

30 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

MOT 

NULL 

CHAR 

1 

NOT 

NULL 

NUMBER 

0 

MOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

8 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

6 

NOT 

NULL 
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ORACLE  DATA  DICTIONARY :  COL  TABLE 


TNAME 

RCBASEDRECSET 

RCKEYWORD 

RECORD  KEY 


RECORD JCEY_MEMBER 

RECORDSET 

RECORD  TYPE 

RECORDTYPECOMP 

RELATION  CLASS 


CNAME 

COLTYP 

WIDTH 

DB  ID 

NUMBER 

0 

RC  NO 

NUMBER 

0 

RT  ID 

CHAR 

30 

SETID 

CHAR 

30 

KW  NO 

NUMBER 

0 

RC_NO 

NUMBER 

0 

DB  ID 

NUMBER 

0 

REC  KEY  DEC  LEN 

NUMBER 

0 

REC  KEY  ID 

NUMBER 

0 

REC  KEY  LABEL 

CHAR 

30 

REC  KEY  UNI  IND 

NUMBER 

0 

REC  KEY  VALUE  LEN 

NUMBER 

0 

RT  ID 

CHAR 

30 

TYPE  ID 

CHAR 

1 

DB  ID 

NUMBER 

0 

DF  ID 

CHAR 

30 

REC  KEY  ID 

NUMBER 

0 

RT  ID 

CHAR 

30 

SEQ  NO 

NUMBER 

0 

DB  ID 

NUMBER 

0 

RT  ID  OF  OWNER 

CHAR 

30 

SET  ID 

CHAR 

30 

SET  NO 

NUMBER 

0 

TOTAL  NUN  MEM 

NUMBER 

0 

DB  ID 

NUMBER 

0 

RT  ID 

CHAR 

30 

RT  NO 

NUMBER 

0 

DB  ID 

NUMBER 

0 

EC  NO 

NUMBER 

0 

RT  ID 

CHAR 

30 

DEP  EC  NO 

NUMBER 

0 

IND  EC  NO 

NUMBER 

0 

MAX  NO  DEP  ENT 

NUMBER 

0 

MIN  NO  DEP  ENT 

NUMBER 

0 

NO  IND  ENT 

NUMBER 

0 

NULLS 


NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 

NOT  NULL 
NOT  NULL 

NOT  NULL 
NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NULL 
NOT  NULL 
NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
NOT  NULL 
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ORACLE  DATA  DICTIONARY:  COL  TABLE 


TNAME 


REUSABLE_NUMBER 

SCHEMANAMES 

SEC 

SECRCCOMPONENT 
SEGMENTDATAF I ELD 

SETTYPEMEMBER 

SOFTWARE  MODULE 


SOFTWARESEC 
SOFTWARE  SUB 


CNAME 


RCNAME 

RC_NO 

AC_NO 

REUSENO 

DB_ID 

DB_LOCATION 

SCHEMANAME 

SUBSCHEMAHAME 

SEC_ID 

VIEWNO 

RC_NO 

VIEW_NO 

DBID 

DFID 

IMSDFIND 

RT_ID 

S  EGSTARTB YTE 
DB_ID 

REQMEMIND 

RT_ID_OF_MEMBER 

SETID 

LANGNAME 

LATEST_REV_DATE 

LATEST_USAGE_DATE 

MODABSTRACT 

MOD_ID 

MOD_TITLE 

STATUSIND 

MOD_ID 

CALLING  MOD  ID 


COLTYP 

WIDTH  NULLS 

CHAR 

30 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

1 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

1 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

10 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

NUMBER 

0 

NOT 

NULL 

CHAR 

60 

NOT 

NULL 

CHAR 

10 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

1 

NOT 

NULL 

CHAR 

10 

NOT 

NULL 

CHAR 

30 

NOT 

NULL 

CHAR 

10 

NOT 

NULL 

1 


ORACLE  DATA  DICTIONARY :  COL  TABLE 


TNAME 

CNAME 

COLTYP 

SUBROUTINE  MOD  ID 

CHAR 

USER  DEF  DATA  TYPE 

DATA  TYPE  IND 

CHAR 

" 

DATA  TYPE  NAME 

CHAR 

DOMAIN  NO 

NUMBER 

MAX  SIZE 

NUMBER 

NO  OF  DECIMALS 

NUMBER 

TYPE  ID 

CHAR 

USDF  DT  NO 

NUMBER 

VERIF  MODULE 

DOMAIN  NO 

NUMBER 

MOD  ID 

CHAR 

DS  620141100 
November  1985 


WIDTH  NULLS 


10  NOT  NULL 
4  NULL 
30  NULL 
0  NULL 
0  NULL 
0  NULL 
1  NULL 
0  NULL 
0  NULL 
10  NULL 
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SECTION  4 

QUALITY  ASSURANCE  PROVISIONS 


4 . 1  Introduction  and  Definitions 

"Testing*  is  a  systematic  process  that  may  be  preplanned 
and  explicitly  stated.  Test  techniques  and  procedures  may  be 
defined  in  advance  and  a  sequence  of  test  steps  may  be 
specified.  "Debugging"  is  the  process  of  isolation  and 
correction  of  the  cause  of  and  error. 

4.2  Computer  Programming  Test  and  Evaluation 

The  quality  assurance  provisions  for  test  will  consist  of 
the  normal  testing  techniques  that  are  accomplished  during  the 
construction  process.  They  consist  of  design  and  code 
walk-throughs,  unit  testing,  and  integration  testing.  These 
tests  will  be  performed  by  the  design  team. 

The  integration  test  developed  for  the  NDDL  will  consist  of 
a  list  of  commands  (and  their  expected  outputs)  which  will  be 
used  by  the  tester.  This  session  will  test  each  command  to 
ensure  its  correct  operation.  Results  of  the  session  may  be 
compared  with  those  of  the  unit  testing. 

Because  rather  flat  hierarchy  of  modules  is  designed  for 
the  NDDL,  unit  testing  will  primarily  involve  testing  each  of 
the  NDDL  interface  routines  and  internal  functions  for  correct 
processing  and  output.  Below  the  level  of  modules  implementing 
each  command  will  be  a  small  set  of  procedures  for  database 
commit  and  rollback  and  error  handling. 
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SECT10H  5 

PREPARATION  FOR  DELIVERY 


The  iepleaentation  site  for  the  constructed  software  will 
be  the  I CAM  Integrated  Support  Systea  (IISS)  Test  Bed  Site 
located  in  Albany,  New  York.  The  software  associated  with  the 
NDDL  will  be  clearly  identified  and  will  include  instructions  on 
procedures  to  be  followed  for  installation  of  the  release. 


